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ABSTRACT 


^  Traditional ly,  the  design  and  impleaientation  o-f  a 
conventional  database  system  begins  with  the  choice  o-f  a 

data  model  followed  by  the  specification  of  a  model -based 

\ 

data  language.  Thus,  the  database  system  is  restricted  to  a 
single  data  model  and  a  specific  data  language.  An 

alternative  to  this  traditional  approach  to  database— system 
development  is  the  multi -lingual  database  system  (I1LDS) . 
This  alternative  approach  enables  the  user  to  access  and 
manage  a  large  collection  of  databases  via  several  data 
models  and  their  corresponding  data  languages  without  the 
aforementioned  restriction. 

^ — Inr  this  thesis  we  ' presentr^the  specification  and 
implementation  of  a  relational /SQL  language  interface  for 
the  MLOS.  Specifically,  wcr  present  the  specification  and 
implementation  of  an  interface  which  translates  SQL  language 


calls  into  attribute— based  data  language  (ABDL)  ^requests. 
We  describe  the  software  engineering  aspects  of  our 
implementation  and  an  overview  of  the  four  modules  which 
comprise  our  relational /SQL  language  interface. 
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Hence,  the  requirements  specification  is  derived  from  the 
above  research. 

We  have  developed  the  design  of  the  system  using 
the  above  specification.  A  Systems  Specification  Language 
<SSL)  CRef.  121  is  used  extensively  during  this  phase.  The 
SSL  has  permitted  us  to  approach  the  design  from  a  very 
high-level,  abstract  perspective  by  : 

(1>  enhancing  communications  Among  progra/ir  team 
members, 

(2)  reducing  dependence  on  any  one  individual,  and 

(3)  producing  complete  and  accurate  documentation 
of  the  design. 

Furthermore,  the  SSL  has  allowed  us  to  make  an  easy 
transition  from  the  design  phase  to  the  coding  phase. 

We  have  used  the  C  programming  language  CRef.  133  to 
translate  the  design  into  executable  code.  Initially,  we 
were  not  conversant  in  the  language.  However,  our 
background  in  Pascal  and  the  simple  syntax  of  C  have  made  it 
easy  for  us  to  learn.  The  biggest  advantage  of  using  C  is 
the  programming  environment  that  it  resides  (i.e.,  the  UNIX 
operating  system).  This  environment  has  permitted  us  to 
partition  the  SQL  interface  and  then  manage  these  parts 
in  an  effective  and  efficient  manner.  Perhaps,  the  only 
disadvantage  with  using  C  is  the  poor  error  diagnostics, 
having  made  debugging  difficult.  There  is  an  on-line 

debugger  available  for  use  with  C  in  UNIX  for  debugging. 
We  have  avoided  this  option  and  instead  used 

25 


results.  The  “black  box”  is  then  decomposed  into  its 
four  modules  (i.e. ,  LIL,  KMS,  KC*  and  KF5) .  These 
modules,  in  turn,  are  further  decomposed  into  the 
necessary  functions  and  procedures  to  accomplish  the 
appropriate  tasks. 

2.  Techniques  for  Software  Development 

In  order  to  achieve  our  design  goals,  it  is 
important  to  employ  effective  ^  software  engineering 
techniques  during  all  phases  of  the-  software  development 
life— cycle.  These  phases,  as  defined  by  Ledthrum  CRef.  11: 
p.  271,  are  as  follows: 

<1)  Requirements  Specification  -  This  phase  involves 
stating  the  purpose  of  the  software:  what  is  to  be 
done,  not  how  it  is  to  be  done. 

(2)  Design  -  During  this  phase  an  algorithm  is  devised 
to  carry  out  the  specification  produced  in  the 
previous  phase.  That  is,  how  to  implement  the  sys¬ 
tem  which  is  specified  during  this  phase. 

<3)  Coding  -  During  this  phase  the  design  is  translated 
into  a  programming  language. 

(4)  Validation  -  During  this  phase  it  is  ensured 
that  the  developed  system  functions  as  originally 
intended.  That  is,  it  is  validated  that  the  system 
actually  performs  what  it  is  supposed  to  do. 

The  first  phase  of  the  life-cycle  has  already 

been  performed.  The  research  done  by  Demur ji an  and  Hsiao 

CRef,  11  has  described  the  motivation,  goals,  and 

structure  of  the  MLDS.  The  research  conducted  by  Macy 

CRef.  21  and  Rollins  CRef.  31  has  extended  this  work  to 

describe  in  detail  the  purpose  of  the  SQL  interface. 


In  addition,  ws  intend  to  make  our  interface 
transparent  to  the  user.  For  example,  an  employee  in  a 
corporate  environment  with  previous  experience  with  SQL 
could  log  into  our  system,  issue  an  SQL  request  and 
receive  result  data  in  a  relational  format,  i.e. ,  a 
table.  The  employee  requires  no  training  in  ABOL  or  liBDS 
procedures  prior  to  utilizing  the  system. 

B.  ,  AN  APPROACH  TO  THE  DESIGN 

1 .  Tfie  Implementation  Strategy 

There  is  a  number  of  different  strategies  we  could 
have  employed  "in  'the  implementation  of  the  SQL  language 
interface.  For  example,  there  are  the  bui Id— i t-twice 
ful 1 -prototype  approach,  the  level -by— level  top-down 
approach,  the  incremental  development  approach,  and  the 
advancemanship  approach  CRef.  10:  pp.  41-461.  We  have 
predicated  our  choice  on  minimizing  the  "software-crisis" 
as  explained  by  Boehm  CRef.  10:  pp.  14-311. 

The  strategy  we  have  decided  upon  is  the  level -by¬ 
level  top-down  approach.  Our  choice  is  based  on,  first, 
a  time  constraint.  The  interface  has  to  be  developed 
within  a  specified  time,  specifically,  by  the  time  we 
graduate.  And  second,  this  approach  lends  itself  to  the 
natural  evolution  of  the  interface.  The  system  is 
initially  thought  of  as  a  "black  box"  (see  Figure  1)  that 
accepts  SQL  transactions  and  then  returns  the  appropriate 


II-  SOFTWARE  ENGINEERING  QF  A  LANGUAGE  INTERFACE 


in  this  chatptsr,  we  discuss  the  various  software 
engineering  aspects  of  developing  a  language  interface. 
First,  we  describe  our  design  goals.  Second,  we  outline 
the  design  approach  that  we  took  to  implement  the  interface. 
Included  in  this  section  are  discussions  of  our 
implementation  strategy,  our  .-software  development 
techniques,  and  salient  characteristics  of  the  language 
interface  software.  Then,  we  provide  a  critique  of  our 
implementation.  Fourth,  we  describe  the  data  structures 
used  in  the  interface.  And  finally,  we  provide  an 
organizational  description  of  the  next  four  chapters. 


A.  DESIGN  GOALS 


We  are  motivated 

to 

implement  an 

SQL 

interface  for 

a 

NLDS  usi ng  MBDS 

as 

the 

kernel 

database 

system. 

the 

attribute— based  data 

model  as 

the  kernel 

data 

model  , 

and 

ABDL  as  the  kernel  data  language.  It  is  important  to  note 
that  we  do  not  propose  changes  to  the  kernel  database  system 
or  language.  Instead,  our  implementation  resides  entirely 
in  the  host  computer.  All  user  transactions  in  SQL  are 
processed  in  the  SQL  interface.  tIBDS  continues  to 
receive  and  process  requests  in  the  syntax  and  semantics  of 


ABDL. 


Appandicas  B,  C,  D,  and  E,  reapactivaly .  Appendix  F  is  a 
usars *  manual  for  the  system.  The  specifications  of  the 
source  data  language,  SQL,  and  of  the  target  data 
language,  ABDL,  can  be  found  in  either  CRef.  93  or 
[Ref.  33. 
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P«r-formanc«  gains  ars  rsalizsd  by  incrsasing  the  numbsr 
of  backsnds.  If  ths  sizs  of  ths  database  and  the  size 
of  the  responses  to  the  transactions  remain  constant,  then 
HBDS  produces  a  reciprocal  decrease  in  the  response 
times  for  the  user  transactions  Mhen  the  number  of 
backends  is  increased.  On  the  other  hand,  if  the  number  of 
backends  is  increased  proportionally  Mith  the  increase  in 
databases  and  responses,  then  nBfiS  produces  .invariant 
response  times  for  the  same  transactions.  A  more 
detailed  discussion  of  liBDS  can  be  found  in  CRef.  83. 

E.  THESIS  OVERVIEW  •’ 

The  organization  of  our  thesis  is  as  follows:  In 
Chapter  2,  we  discuss  the  software  engineering  aspects  of 
our  implementation.  This  includes  a  discussion  of  our 
design  approach  as  well  as  a  review  of  the  global  data 
structures  used  for  the  implementation.  In  Chapter  3,  we 
outline  the  functionality  of  the  language  interface 
layer.  In  Chapter  4,  we  articulate  the  processes 
constituting  the  kernel  mapping  system.  In  Chapter  5,  we 
provide  an  overview  of  the  kernel  controller.  In  Chapter 

6,  we  describe  the  kernel  formatting  system.  In  Chapter 

7,  we  conclude  the  thesis. 

Appendix  A  covers  the  data  structures  diagrams  for  the 
shared  and  local  data.  The  detailed  specifications  of  the 
interface  modules,  i.e.,  LIL,  KMS,  KC,  and  KF5,  are  given  in 
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'fashion.  These  backends  have  identical  hardware  and 
replicated  software  and  their  own  disk  systems.  In  a 
multiple  backend  configuration,  there  is  a  backend 
controller,  which  is  responsible  for  supervising  the 
execution  of  database  transactions  and  for  interfacing 
with  the  hosts  and  users.  The  backends  perform  the 
database  operations  with  the  database  stored  on  the  disk 
system  of  the  backends.  The  controller  and  backends  are 
connected  by  a  communication  bus.  Users  access  the  system 
through  either  the  hosts  or  the  controller  directly  (See 
Figure  2) . 


Dackfnd  Store  t 


Communications 

Bus 

Figure  2.  The  liul  ti -Backend  Database  System. 
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supporting  ths  rsquirsd  data— niodsl  transformations  and 
data— 1 anguags  translations  for  ths  language  interfaces. 

The  attribute-based  data  model  proposed  by  Hsiao 
CRef.  43,  extended  by  Wong  CRef.  S3,  and  studied  by  Rothnie 
CRef.  63,  along  with  the  attribute— based  data  language 
(ABDL) ,  defined  by  Banerjee  CRef.  73,  have  been  shown  to  be 
acceptable  candidates  for  the  kernel  data  model  and  kernel 
data  language,  respectively.  « 

*'  Why  is  the  determination  of  a  kgrnsl  data  model  and 
kernel  data  language  so  important  for  a  MLBS?  No  matter  how 
mul ti— 1 ingual  the  MLDS  may  be,  if  the  underlying  database 
system  (i.e. ,  KDS)  is  slow  and  inefficient,  then  the 
interfaces  may  be  rendered  useless  and  untimely.  Hence, 
it  is  important  that  the  kernel  data  model  and  kernel 
language  be  supported  by  a  high-performance  and  great- 
capacity  database  system.  Currently,  only  the 
attribute-based  data  model  and  the  attribute-based  data 
language  are  supported  by  such  a  system.  This  system  is 
the  mul ti -backend  database  system  <HBDS)  CRef.  13. 

D.  THE  MULT I -BACKEND  DATABASE  SYSTEM 

The  multi -backend  database  system  (MBDS)  has  been 
designed  to  overcome  the  performance  problems  and  upgrade 
issues  related  to  the  traditional  approach  of  database 
system  desigri.  This  goal  is  realized  through  the 
utilization  of  multiple  backends  connected  in  a  parallel 


fflodulas  are  required  for  each  other  language  interface  of 


the  MLDS.  For  example,  there  are  four  sets  of  these 
modules  where  one  set  is  for  the  relational /SQL.  language 
interface,  one  for  the  hierarchical /DL/ I  language 
interface,  one  for  the  network/CODASYL  language 
interface,  and  the  last  one  for  the  entity- 
relationship/Daplex  language  interface.  However,  if  the 
user  writes  the  transaction  in  the  native  mode,  i.e^  in  KDL, 
there  is  no  need  of  any  interface. 

In  our  implementation  of  the  relational /SQL 
language  interface,  we  develop  the  code  for  the  four 
modules.  However,  we  do  not  integrate  these  modules  with  the 
KDS  as  shown  in  Figure  1.  The  Laboratory  of  Database 
Systems  Research  at  the  Naval  Postgraduate  School  is  in  the 
process  of  procuring  new  computer  equipment  for  the  KDS. 
When  the  equipment  is  installed,  the  KDS  will  be  ported  over 
to  the  new  equipment.  The  MLDS  software  will  then  be 
integrated  with  the  KDS.  Although  not  a  very  difficult 
undertaking,  it  may  be  time  consuming. 


C.  THE  KERNEL  DATA  MODEL  AND  LANGUAGE 


The  choice  of  a  kernel  data  model  and  a  kernel  data 
language  is  the  key  decision  in  the  development  of  a 
multi-lingual  database  system.  The  overriding  question, 
when  making  such  a  choice,  is  whether  the  kernel  data 
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Figure  1'.'  The  liul ti -Lingual  Database  System. 

the  KDM  database  de-finition,  it  in-forms  the  KC.  The  KC 
then  notifies  the  user  via  the  LIL  that  the  database 
definition  has  been  processed  and  that  the  loading  of  the 
database  records  may  begin.  In  the  second  task,  the  KMS 
sends  the  KDL  transactions  to  the  KC.  When  the  KC 

receives  the  KDL  transactions,  it  forwards  them  to  the 
KDS  for  execution.  Upon  completion,  the  KDS  sends  the 
results  in  KDM  form  back  to  the  KC.  The  KC  routes  the 
results  to  the  kernel  fociDStting  system  <KFS)  .  The  KFS 
reformats  the  results  from  KDM  form  to  UDM  form.  The  KFS 
then  displays  the  results  in  the  correct  UDM  form  via  the 
LIL. 

The  four  modules,  LIL,  KMS,  KC,  and  KFS,  are 
collectively  known  as  the  Language  LQtS^lice.  Four  similar 


LR»t.  3 j ,  Mho  havs  showad  tha  -feasibility  of  this  particular 
interface  in  a  MLDS. 


B.  THE  MULT I -LINGUAL  DATABASE  SYSTEM 

A  detailed  discussion  of  each  of  the  components  of  a 
MLDS  is  provided  in  subsequent  chapters.  In  this  section  we 
provide  an  overview  of  the  organization  of  a  MLDS.  This 

can  assist  the  reader  in  understanding  how  the 

•I 

different  components  of  the  MLDS  are  related. 

Figure  1  shows  the  system  structure  of  a  multi¬ 


lingual  database  system. 


The  user  interacts  with  the 


system  through  the  1 anouage  interface  layer  (LID  using  a 
chosen  user  data  model  (UDM)  to  issue  transactions  written 
in  a  corresponding  model -based  user  data  language  (UDL) . 
The  LIL  routes  the  user  transactions  to  the  kernel 
maoDino  3y3^StS  (KM^)  .  The  KMS  performs  one  of  two 

passible  tasks.  First,  the  KMS  transforms  a  UDM-based 
database  definition  to  a  database  definition  of  the  kernel 
(SSdSl  (KDM)  when  the  user  specifies  that  a  new  database 
is  to  be  created.  When  the  user  specifies  that  a  UDL 
transaction  is  to  be  executed,  the  KMS  translates  the  UDL 
transaction  to  a  transaction  in  the  kernel  data  language 
•  In  the  first  task,  the  KMS  forwards  the  KDM  data 
definition  to  the  kernei  controller  (KC) .  The  KC,  in  turn, 
sends  the  KDM  database  definition  to  the  kernel  database 
system  (KDS) .  When  the  KDS  is  finished  with  processing 


The  MLDS  providas  tha  sama  rasulta  avan  if  tha  data  languaga 
of  tha  '  transaction  is  originatad  at  a  diffarant  database 
systam. 

A  second  advantage  deals  with  the  economy  and 
effectiveness  of  hardware  upgrade.  Frequently,  the 
hardware  supporting  the  database  systam  is  upgraded 
because  of  technological  advancements  or  system 
demand.  With  the  traditional  approach,  this  '  type  of 
hardware  upgrade  has  to  be  provided  for  all  of  the  different 
database  systems  in  use,  so  that  all  of  the  users  can 
experience  system  p^erformance  improvements.  This  is  not 
the  case  in  MLDS,  where  only  the  upgrade  of  a  single 
system  is  necessary.  In  a  MLDS,  the  benefits  of  a  hardware 
upgrade  are  uniformly  distributed  across  all  users,  despite 
their  use  of  different  models  and  data  languages. 

Thirdly,  a  multi -lingual  database  system  allows  users 
to  explore  the  desirable  features  of  the  different  data 
models  and  then  use  these  to  better  support  their 
applications.  This  is  possible  because  MLDS  supports  a 
variety  of  databases  structured  in  any  of  the  well-known 
data  models. 

It  is  apparent  that  there  exists  ample  motivation  to 
develop  a  mul ti — 1 ingual  database  system  with  many  data 
model /data  language  interfaces.  In  this  thesis,  we  are 
developing  a  relational /SQL  languaga  interface  for  the  MLDS. 
We  are  extending  the  work  of  Macy  CRef.  21  and  Rollins 


Mhich  supports  tha  rslationai  modal  and  tha  ral at tonal - 
modal -basad  data  language.  Structured  English  Query 
Language  (SQL) .  The  result  o-f  this  traditional  approach 
to  database  system  development  is  a  homogeneous  database 
system  that  restricts  the  user  to  a  single  data  model  and  a 
spaci-fic  model -basad  data  language. 

An  unconventional  approach  to  database  system 
development,  re-f erred  to  '  as  the)  Mul ti-1  inoual-  database 
system  (MLDS)  CRe-f.  11,  alleviates:  the  aforementioned 
restriction.  This  new  system  affords  the  user  the  ability 
to  access  and^  manage  a  large  collection  of  databases  via 

*•  t  ‘  * 

several  data  models  and  thair  corresponding  data  languages. 
The  design  goals  of  MLDS  involve  developing  a  system 
that  is  accessible  via  a  relational /SQL  interface,  an 
hierarchical/DL/I  interface,  a  network /CODASYL 
interface,  and  an  enti ty— relationship/Daplex  interface. 

There  is  a  number  of  advantages  in  developing  such  a 
system.  Perhaps  the  most  practical  of  these  involves  the 
reusability  of  database  transactions  developed  on  an 
existing  database  system.  In  liLDS,  there  is  no  need 
for  the  user  to  convert  a  transaction  from  one  data 
language  to  another  data  language.  The  MLDS  permits  the 
running  of  database  transactions  written  in  different  data 
languages.  Hence,  the  user  does  not  have  to  perform 
either  a  manual  or  automated  translation  of  an  existing 
transaction  in  order  to  execute  the  transaction  in  MLDS. 


I -  INTRODUCTION 


A.  MOTIVATION 

During  the  past  twenty  years  database  systems  have  been 
designed  and  implemented  using  what  we  re-fer  to  as 
the  traditional  approach.  The  first^step  in  the  traditional 
approach  involves  choosing  a  data , model .  Candidate  data 
models  include  the  relational  data  model ,  the  hierarchical 
data  model,  the  network  data  model,  the  entity-relationship 
data  model  ,  or  the  attribute-based  data  model  to  name  a  -few. 
The  second  step  speci-fies  a  model-based  data  language,  e.g., 
SQL  or  QUEL  -for  the  relational  data  model,  or  Oaplex  for  the 
entity-relationship  data  model. 

A  number  of  database  systems  have  been  developed  using 
this  methodology.  For  example,  there  is  IBM's 
Information  Management  System  (IMS)  since  the  sixties, 
which  supports  the  hierarchical  data  model  and  the 
hierarchical -model -based  data  language,  Data  Language  I 
(DL/I).  Sperry  Uni  vac  has  introduced  the  DMS-1100  in  the 
early  seventies,  which  supports. the  network  data  model  and 
the  network-model -based  data  language,  CODASYL  Data 
Manipulation  Language  (CODASYL-DML) .  And  more  recently, 
there  has  been  IBM's  introduction  of  the  SQL/Data  System 


conditional  compilation  and  diagnostic  print  statements 
to  aid  in  the  debugging  process.  To  validate  our 
system  we  have  used  a  traditional  testing  technique, 
i.e.,  path  testing  CRe-f.  141.  We  have  checked  boundary 
cases  such  as  the  nested  select  and  the  single  select. 
And  we  have  tested  those  cases  considered  "normal".  It 
is  noteworthy  to  mention  that  testing,  as  we  have  done  it, 
does  not  prove  the  system  correct,  fiut  can  only  '  indicate 
the  absence  o-f  problems  with  the-  cases  that  have  been 
tested. 

3.  Character i stipes  of  the  Interface  Software 

In  order  -for  the  SQL  inter-face  to  be  successful  ,  we 
have  realized  that  it  must  be  well  designed  and  well 
structured.  Hence,  we  are  cognizant  of  certain 
characteristics  that  the  interface  must  possess. 
Specifically,  it  must  be  simple.  In  other  words,  it  must  be 
easy  to  read  and  comprehend.  The  C  code  we  have  written 
has  this  characteristic.  For  instance,  we  often  write  the 
code  with  extra  lines  to  avoid  shorthand  notations 
available  in  C.  These  extra  lines  have  made  the 
difference  between  comprehensible  code  and  cryptic 
notations. 

The  interface  software  also  must  be  understandable. 
This  must  be  true  to  the  extent  that  a  maintenance 
programmer,  for  example,  can  easily  grasp  the 
functionality  of  the  interface  and  the  relation  between  it 


and  the  other  pieces  of  the  system.  Our  software 
possesses  this  characteristic-  and  does  not  have  any  hidden 
side-effects  that  could  pose  problems  months  or  years  from 
now.  As  a  matter  of  fact,  we  have  intentionally 
minimized  the  interaction  between  procedures  to  alleviate 
this  problem. 

The  interface  must  also  be  maintainable.  This  is 
important  iri  light  of  the  fact  tfiat  almost  70X  of  all  of 
the  software  life— cycle  costs  are  incurred  after  the 
software  becomes  operational,  i.e. ,  in  the  maintenance 
phase.  There  are  software  engineering  techniques  we 
employed  that  have  given  the  SQL  interface  this 
characteristic.  For  example,  we  require  programmers  to 
document  changes  to  the  interface  code  when  the  change  is 
made.  Hence,  maintenance  programmers  have  current 
documentation  at  all  times.  The  problem  of  trying  to 
figure  out  the  functional -ty  of  a  program  with  dated 
documentation  is  alleviated.  We  also  required  the 
programmers  to  update  their  SSL  specification  as  the  code  is 
being  changed.  Thus,  the  SSL  specification  consistently 
corresponds  to  the  actual  code.  In  addition,  the  data 
structures  are  designed  to  be  general.  Thus,  it  is  an  easy 
task  to  modify  or  rectify  these  structures  to  meet  the 
demands  of  an  evolving  system. 

The  research  conducted  by  Demur ji an  and  Hsiao 
CRef.  11  provides  a  high-level  specification  of  the  MLDS. 


The  theses  written  by  liacy  CRe-f.  22  and  Rollins  CRef.  33 
extend  the  above  work  and  provide  a  more  detailed 
specification  of  an  SQL  language  interface.  This 
thesis  outlines  the  actual  implementation  of  an  SQL 
interface.  The  appendices  provide  the  specification  SSL 
for  this  implementation. 

A  final  characteristic 'that  an  SQL  interface  should 
have  is  extensibility.  A  software  product  must  be  designed 
in -'a  manner  that  permits  the  easy  moefif  ication  and  addition 
of  code.  In  this  light,  we  have  placed  "stubs”  in  the 
correct  locations  of  the  KFS  to  permit  the  easy 
insertion  of  the  code  needed  to  handle  multiple 
horizontal  screens  of  output.  In  addition,  we  have 
designed  our  data  structures  in  a-  manner  that  will 
permit  subsequent  programmers  to  easily  extend  them  to 
handle  not  only  multiple  users,  but  also  other  language 
interfaces. 

C.  A  CRITIQUE  OF  THE  DESIGN 

Our  implementation  of  the  SQL  interface  possesses  all  of 
the  elements  of  a  successful  software  product.  As  noted 
previously,  it  is  simple,  understandabl e,  maintainable,  and 
extensible.  Our  constant  employment  of  modern  software 
techniques  have  ensured  the  success. 

However,  there  are  two  techniques  that  are  especially 
worthy  of  critiques.  The  first  of  these  is  the  use 


o-F  the  SSL 


Initially, 


wi 


have  -felt  that 


the 


ifl^lementation  language  may  also  serve  as  the  language  to 
speci-Fy  program  algorithms.  However,  in  doing  so,  we  have 
stifled  our  creativity.  This  is  because  we  are 
concentrating  not  only  on  what  the  algorithm  does,  but 
also  on  what  the  constructs  (data  structures)  of  the 
algorithm  are.  The  use  of  the  SSL  has  permitted  us  to 
concentrate  on  the  functionality  of 'the  algorithm  without  a 
he^vy  concentration  on  its  particular  -.constructs.  This  has 
allowed  us  to  view  the  algorithm  in  a  detached  manner  so 
that  the  most  efficient  implementation  for  the 
constructs  can  be  used.  Although  we  have  initially  felt 
that  the  development  of  the  program  with  the  SSL  may  be  too 
time-consuming,  our  opinions  are  changed  when  we  have 
realized  the  advantages  of  the  SSL  and  the  overall 
complexity  of  the  SQL  language  interface. 

The  way  in  which  the  data  structures  are  designed  is 
the  other  noteworthy  software  engineering  technique. 
Being  relatively  inexperienced  programmers,  we  are 
inclined  to  use  static  structures.  Hence,  we  have  made 
extensive  use  of  structures  which  are  bound  at  compile  time. 
We  soon  realize  that  in  doing  so,  the  computing  resources 
(e.g.,  data  space)  of  the  system  are  being  depleted  quite 
rapidly.  Therefore,  it  is  necessary  for  us  to  design  the 
data  structures  in  a  way  that  they  can  be  managed  in  a 


dynami c 


fashion. 


Most  of  the  data  structures  of  the 


SQL  intBr-faca  ars  linked  lists.  This  design  a-ftords  us 
the  most  convenient  way  to  ef-ficiently  utilize  the 
resources  o-f  the  system.  It  is  an  easy  task  to  use  the  C 
language's  malloc  (memory  allocate)  -function  to 
dynamically  create  the  elements  o-f  a  list  as  we  have  needed 


them. 


In  addition,  the  -free  command  is  use-ful  in 


releasing  these  same  elements  to  be  used  again. 


D.  THE  DATA  STRUCTURE 

The  SQL  language  inter-face  has  been  developed  as  a 
single  user  system  that  at  some  point  will  be  updated  to  a 
multi-user  system.  'Two  di-f-ferent  concepts  o-f  the  data  are 
used  in  the  language  interface 

1.  Data  shared  by  all  users. 

2.  Data  specific  to  each  user. 

The  reader  must  realize  that  the  data  structures  used 

in  our  interface  and  described  below  have  been 

deliberately  made  generic.  Hence,  these  same  structures 
support  not  only  our  SQL  interface,  but  the  other  language 
interfaces  as  well,  i.e.,  DL/I,  C0DA5YL-DHL,  and  Daplex. 

1 .  Data  Shared  by  A1.1.  U§g!15 

The  data  structures  that  are  shared  by  all  users 

are  the  database  schemas  defined  by  the  users  thus  far. 

In  our  case,  these  are  relational  schemas,  consisting 
of  relations  and  attributes.  These  are  not  only  shared 


by  all  users. 


but  also  shared  by  the  four  modules  of  the 


MLDSf  i.e. t  LIL,  KMS,  KC,  and  KFS.  Figura  3  depicts  the 
-first  data  structure  used  to  qtaintain  data.  It  is 
important  to  note  that  this  structure  is  represented  as 
union.  Hence,  it  is  generic  in  the  sense  that  a  user  can 
utilize  this  structure  to  support  SQL,  DL/I,  CODASYL-DHL, 
or  Oapiex  needs.  However,  we  will  concentrate  only  on 
the  relational  model.  In  this  regard,  the  first  -Field  of 
this  structure  points  to  a  retord  that  '  contains 
in-f'ormation  about  a  relational  .<  database.  Figure  4 
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union  dbid_node 

< 

struct  ral_dbid_node  -*rBl ; 

struct  hie_dbid_node  -*hie; 

struct  net_dbid_node  -»net; 

struct  ent  dbid  node  »ent; 

> 

Figure  3.  The  dbid_node  Data  Structure. 


struct  rel_dbid_node 

C 

char  nameCDBNLength  11; 

int  num_rel ; 

struct  rel_node  ■»first_rel; 

struct  rel_node  *curr_rBl ; 

struct  rel_dbid_node  •»next_db; 

> 

Figure  4.  The  rel _dbi d_node  Data  Structure. 


raprassnting  ths  number  of  relations  in  the  database.  The 
third  and  fourth  fields  are  pointers  to  other  records 
containing  information  about  each  relation  in  the  database. 
Specifically,  the  third  field  points  to  the  first  relation 
in  the  database  while  the  fourth  field  points  to  the 
current  relation  being  accessed.  The  final  field  is  just  a 
pointer  to  the  next  relational  database. 

The  record  rel_node  contains) inf ormati on  about  each 
re(^tion  in  the  database.  (See  Figure  5.)  This  structure 
is  organized  in  much  the  same  fashion  that  the  rel_dbid_node 
is  organized.^  The  first  field  of  the  record  holds  the  name 
of  the  relation.  The  next  field  contains  the  number  of 
attributes  in  this  relation.  The  third  and  fourth  fields 
point  to  other  records  which  contain  data  on  the  first 
and  current  attribute  of  this  relation.  And  finally, 
the  last  field  is  a  pointer  to  the  next  relation  in  this 
database. 

struct  rel_node 

< 

char  nameCRNLength  +  11; 

int  num_attr; 

struct  rattr^node  *first_attr; 

struct  rattr_node  ■»curr_attr; 

struct  rel_node  ♦next  rel ; 

1 

Figure  5.  The  rel_node  Data  Structure. 


Figurs  6  shows  the  structure  o-f  the  -final  record 
type  used  to  support  the  de-finition  o-f  the  relational 
database  schema.  The  -first  -field  is  also  an  array, 
holding,  in  this  case,  the  name  o-f  the  attribute.  The 
second  -field  serves  as  a  flag  to  indicate  the  attribute 
type.  For  instance,  an  attribute  can  either  be  an  integer, 
a  floating  point  number,  or  a  string.  The  characters 
"i",  "f,  and  "s”  are  used,  respectively.  The  third 
fi^ld  indicates  the  maximum  length  that  a  value  of  this 
attribute  type  may  possibly  have.  For  example,  if  this 
field  is  set  to  ten  and  the  type  of  this  attribute  is  a 
string,  then  the  maximum  number  of  characters  that  a 
value  of  this  attribute  type  may  have  is  ten.  The  fourth 
field  is  also  a  flag  used  to  indicate  whether  or  not 
this  particular  attribute  is  a  key.  The  last  attribute 
just  points  to  the  next  attribute  in  this  relation.  The 
reader  may  refer  to  Appendices  B  through  E  to  examine  how 
these  data  structures  are  used  in  the  SSL. 

struct  rattr_node 

<. 

char 
char 
int 
int 

struct  rattr_node 

J 

Figure  6.  The  rattr_node  Data  Structure. 


nameCANLength  -«■  11; 

type; 

length; 

kBy_f lag; 

-*next ; 


2.  Qa£a  SE»s£i£i£  ts  iasi!  Ussc 


This  catsgory  o-F  data  rsprssants  in-formation 
nseded  to  support  each  user's  particular  inter -face 
needs.  The  data  structures  used  to  accomplish  this  can 
be  thought  o-f  as  -forming  a  hierarchy.  At  the  root  o-f  this 
hierarchy  is  the  record  type  user_in-fo  that  maintains 
in-formation  on  all  o-f  the  current  users  o-f  a  particular 
language  intdr-face.  (See  Figure  7.)*  The  user_in-fo  record 
hofds  the  ID  o-f  the  user,.  a  union  that  describes  a 
particular  inter -face,  and  a  pointer  to  the  nei<t  user.  The 
union  field  is  of  particular  interest  to  us.  As  noted 
earlier,  a  union  serves  as  a  generic  data  structure.  In 
this  case,  the  union  can  hold  the  data  for  a  user  accessing 
either  an  SQL  language  interface,  a  DL/I  LIL,  a  CODASYL- 
DML  LIL,  or  a  Daplex  LIL.  The  li_info  union  is  shown  in 
Figure  8. 

We  are  only  interested  in  the  data  structures 
containing  information  for  each  user  that  pertains  to  the 
SQL  language  interface.  This  structure  is  referred  to  as 

struct  user_info 

<. 

char  uidCUIOLength  11; 

union  li_info  li_type; 

struct  user_info  ♦next  user; 

1 

Figure  7.  The  user_info  Data  Structure. 


union  li_in-fo 
< 


struct 

sql_inf o 

sql; 

struct 

dli_inf o 

dli ; 

struct 

dml_inf o 

dml ; 

struct 

dap_inf o 

dap; 

> 

Figure  8.  The  li_i»-fo  Data  Structure. 

sql_in-fo  and  is  depicted  in  Figure  9.  The  first  field  of 
this  structure,  curr_db_inf o,  is<  itself  a  recbrd  and 

corirtains  currency  information  on  the  database  being  accessed 
by  a  user.  The  second  field,  file,  is  also  a  record.  The 
file  record  contains  the  file  descriptor  and  file  identifier 
of  a  file  of  SQL  transactions,  i.e. ,  either  queries  or 
creates.  The  next  field,  sql_tran,  is  also  a  record,  and 
holds  information  that  describes  the  SQL  transactions 
to  be  processed.  This  includes  the  number  of  requests  to 
be  processed,  the  first  request  to  be  processed,  and  the 
struct  sql_info 


struct 

curr_db_inf o 

curr_db; 

struct 

f ile_inf o 

file; 

struct 

tran_inf o 

5ql_tran; 

i  nt 

operation; 

struct 

ddl_inf o 

*ddl_f iles 

struct 

tran_inf o 

♦abdl _tran 

uni  on 

kms_inf o 

kms_data; 

union 

kf s_inf o 

kf s_data; 

union 

kc_i nf o 

kc_data; 

int 

, error; 

Figure  9.  The  sql_info  Data  Structure. 
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current  request  being  processed.  The  -fourth  field  of  the 
sql_info  record,  operation,  is  a  flag  that  indicates  the 
operation  to  be  performed.  This  can  be  either  the  loading 
of  a  new  database  or  the  execution  of  a  request 
against  an  existing  database.  When  this  field  represents 
the  execution  of  a  request,  it  is  encoded  with  the  ABDL 
request  type  to  be  executed.  The  next  field,  ddl_files, 
is  a  pointer  to  a  structure  describing  the  descriptor  file 
and'  template  file.  These  files  contain  information  about 
the  ABDL  schema  corresponding  to  the  current  relational 
database  being  processed,  i.e.  the  ABDL  schema 
information  for  a  newly  defined  relational  database.  The 
sixth  field,  abdl_tran,  is  a  pointer  to  a  record  that 
describes  the  ABDL  equivalents  to  the  transactions  written 
in  SQL  i.e.,  the  translated  SQL  requests. 
Specifically,  this  is  the  first  ABDL  request,  the  current 
ABDL  request,  and  the  number  of  ABDL  requests  to  be 
processed.  This  data  is  provided  by  the  KhS  and  used  by 
the  KC.  The  next  three  fields,  kms_data,  kc_data,  and 
kfs_data,  are  unions  that  contain  information  that  is 
required  by  the  KMS,  KC,  and  KFS.  These  will  be  described 
in  more  detail  in  the  next  four  chapters.  The  last 
field,  error,  is  an  integer  value  representing  a  specific 
error  type. 
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E.  THE  ORGANIZATION  OF  THE  NEXT  FOUR  CHAPTERS 

The  following  four  chapters  are  meant  to  provide  the 
user  with  a  more  detailed  analysis  of  the  modules 
constituting  the  NLDS.  Each  chapter  will  begin  with  an 
overview  of  what  each  particular  module  does  and  how  it 
relates  to  the  other  modules.  The  actual  processes 
performed  by  each  module  are  then  discussed.  This  includes  a 
description  of  the  actual'  data  structures  used-  by  the 
modules.  Each  chapter  concludes  .-with  a  discussion  of 
module  shortcomings. 
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Ill 


THE  LANBUAGE  INTERFACE  LEAVER  (LID 


The  LIL  is  the  -First  module  in  the  SQL  mapping  process, 
and  is  used  to  control  the  order  in  which  the  other 
modules  are  called.  The  LIL  allows  the  user  to  input 
transactions  -from  either  a  -file  or  the  terminal.  A 
transaction  can  take  the  -Form  o-F  either  creates  -For  a  new 
database  or  queries  against  an  existing  database.  The 
mapping  process  takes  place  when  the  LIL  sends  a  single 
transaction  to .  the  .  KMS.  A-Fter  the  transaction  has  been 
received  by  the  KMS,  the  KC  is  called  to  process  the 
transaction.  Control  always  returns  to  the  LIL,  where  the 
user  can  close  the  session  by  exiting  to  the  operating 
system. 

The  LIL  is  menu-driven.  When  the  transactions  are  read 
■From  either  a  -File  or  the  terminal  they  are  stored  in  a  data 
structure  called  rel _req_in-f o.  If  the  transactions  are 
creates  they  are  sent  to  the  KMS  in  sequential  order.  If 
the  transactions  are  queries  the  user  will  be  prompted  by 
another  menu  to  selectively  pick  an  individual  query  to  be 
processed.  The  menus  provide  an  easy  and  efficient  way  to 
allow  the  user  to  see  and  select  the  methods  in  which  to 
perform  the  mapping  functions.  Each  menu  is  tied  to  its 
predecessor  so  that  by  exiting  each  menu  the  user  is  being 


38 


moved  up  the  menu  "tree".  This  allows  the  user  to  perform 
multiple  tasks  in  one  session. 

A.  THE  LIL  PROCESS 

In  this  section  we  discuss  the  processes  and  actions 
performed  by  the  LIL.  These  processes  are  presented  in 
the  order  in  which  they  are  encountered  during  a 

typical  session.  The  data  structures  used  heavily  by 

i 

the  LIL  are  discussed  first. 

1 .  Important  Data  Structures 

The  LIL  uses  two  data  structures  to  store  the 
user's  transattf ons  'and  to  control  which  transaction  is  to 
be  sent  to  the  KMS.  It  is  important  to  note  here  that 
these  data  structures  are  shared  by  both  the  LIL  and  the 
KMS. 

The  first  structure  is  named  tran_info  and  is  shown 
in  Figure  10.  The  first  field  of  this  record,  first_rBq, 


contains  the  address 

of 

the 

first 

transaction 

of  the 

transaction  list  that 

was 

read 

from 

a  file 

or  the 

terminal.  The  second  field,  curr_req,  contains  the 

struct  tran_info 

C 

struct  rel_req_info  ♦first_rBq; 
struct  rel_req_info  *curr_req; 
int  no_req; 

J 

Figure  10.  The  tran_info  Data  Structure. 


user.  The  LIL  then  sends  the  KMS  one  database  de-finition  at 
a  time,  which  takes  the  -form  of  an  SQL  CREATE  TABLE  request 
as  -follows: 

CREATE  TABLE  table_name  : 

■f ield_name_l  (  type(length)  C,  NONULL]  ), 
fieldlname_2  (  type (length)  C,  NONULL 1  ), 

■  «  « 

■f ield_name_n  <  typ4( length)  C,  NONULL  1  ) 

For  each  CREATE  TABLE  request,  an  additional  relation  node 
<rel_node  shown  in  Figure  5)  is  added  to  the  database  schema 
under  construction.  It  should  be  apparent  from  the 
preceding  CREATE  TABLE  example  that  for  each  relation  node, 
we  must  also  add  a  list  of  attribute  nodes  (rattr_node  shown 
in  Figure  6)  to  the  schema.  The  database  identification 
node  holds  the  number  of  relations  in  the  schema  and  the 
database  name,  each  relation  node  holds  the  number  of 
attributes  in  that  relation  and  the  relation  name,  and  each 
attribute  node  holds  the  attribute  name,  type,  length,  and 
primary  key  information. 

Nhen  the  LIL  has  forwarded  all  database  definitions 
entered  by  the  user,  the  result  is  a  completed  database 
schema,  -as  shown  in  Figure  14.  The  relational  database 
schema,  when  completed,  serves  two  purposes.  First,  when 
creating  a  new  database,  it  facilitates  the  construction  of 
the  MBDS  template  and  descriptor  files.  Secondly,  when 
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attribute  values  in 

the 

database 

is 

limited 

only 

by  the 

constraint  placed 

on 

them  by 

the 

user 

in  the 

original 

database  definition 

,  and 

as  such 

they 

may 

be  of 

varying 

lengths. 

At  the  end  o-f  the  mapping  process,  be-fore  control  is 
surrendered  to  the  LIL,  all  data  structures  that  are  unique 
to  KMS  which  have  been  allocated  during  the  mapping  process 
are  returned  to  the  free  list.  % 

B.  FACILITIES  PROVIDED  BY  THE  IMPLEMENTATION 

In  this  section,  we  discuss  those  SQL  facilities  that 
are  provided  -by  our  implementation  of  the  relational 
interface.  We  do  not  discuss  the  SQL  to  ABDL  translation  in 
detail.  Rather,  we  provide  an  overview  of  the  salient 
features  of  the  KMS,  accompanied  by  one  illustrative  example 
of  the  mapping  process.  User — issued  requests  may  take  two 
forms,  SQL  database  definitions,  or  SQL  database 
manipulations.  Appendix  C  contains  the  design  of  our 
implementation,  written  in  a  system  specification  language. 

1 Definitions 

When  the  user  informs  the  LIL  that  the  user  wishes 
to  create  a  new  database,  the  job  of  the  KMS  is  to  build  a 
relational  database  schema  that  corresponds  to  the  database 
definitions  input  by  the  user.  The  LIL  initially  allocates 
a  new  database  identification  node  (rel _dbi d_node  shown  in 
Figure  4)  with  the  name  of  the  new  database,  as  input  by  the 


»  -  •<  -  ^  . 
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M*  raquir*  m  list  o-f  rel_kms_inf  o  structures,  one 
corresponding  to  each  level  o-f  the  nested  SELECT  query. 

The  remaining  three  data  structures,  shown  in  Figure 
13,  are  records  that  are  pointed  to  by  the  rel_kms_in-f o 
record,  as  Just  described.  Respectively,  they  represent  a 
list  o-f  attribute  names  (the  target  list)  ,  a  record  o-f 
relation  names  (the  templates),  and  a  list  o-f  attribute 
values  (the  insert  list).  ANLeAgth  and  RNLehgth  are 
constants  de-fining  the  maximum  lengths  o-f  attribute  and 
relation  names,  respectively.  It  should  be  noted  that  the 
value  -field  in  the  insert_l ist_in-fo  record  is  a  pointer  to  a 
variable  length  character  string.  Although  attribute-names 
have  a  constant  maximum  length  constraint,  the  length  of 


struct  target  list  info 

char  nameCANLength  -*•  11; 

char  tgt_rel  CRNLength  -*•  ID; 

struct  targBt_l ist^inf o  ♦next_attr; 

\ 

J 

struct  tempi ates_info 
C 

char  namel CRNLength  +  11; 
char  name2CRNLength  +  11; 

y 

struct  i nsert_l i 5t_inf o 
{ 

char  -H-value; 

struct  insert_list_inf  o  •»next_val; 


Figure  13.  Additional  KhS  Data  Structures. 
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struct  rBl_kms_in-fo 
i  ~  ~ 

struct  target_list_in-fo  *-first_tgt; 
struct  tempi  ates_in-fo  templates; 
struct  insert_liBt_in-fo  ♦•fir5t_val; 
char  *temp-str ; 

char  *join_Btr; 

struct  rBl_kms_in-fo  *next  nest; 

Figure  12.  The  rel_kms_in-f o  Data  Structure. 

operations,  two  relation  names  may  be  kept  in  this  record. 

r 

The  third  -field,  first_val,  is  a  pointer  to  the  head  of  a 
list  of  values.  These  are  the  values  that  an  INSERT  request 
desires  inserted  into  the  database.  The  fourth  field, 
temp_str,  is  a  pointer  to  a  variable— length  character 
string.  The  character — string  length  is  a  function  of  the 
input  request  length,  and  is  allocated,  when  required,  to 
accumulate  intermediate  translation  results  while  parsing 
the  WHERE  boolean-clause  of  a  user  request.  The  fifth 
field,  join_str,  is  also  a  pointer  to  a  variable  length 
character  string.  The  character — string  length  is  again  a 
function  of  the  input  request  length,  and  it  is  allocated  to 
accumulate  the  translation  for  the  second  ABDL  RETRIEVE 
request  that  is  generated  in  response  to  a  join  operation. 
The  sixth  field,  next_nest,  is  a  pointer  to  another  record 
of  the  same  type.  The  next_nest  field  is  used  only  during 
the  translation  of  a  nested  SELECT  statement,  in  which  case 
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lower-l«v«l  grammar  rules  have  been  satisfied  and  control 
has  ascended  to  the  highest-level  rule,  the  parsing  and 
translation  processes,  and,  therefore,  the  mapping  process, 
is  complete.  In  Section  B,  we  give  an  illustrative  example 
of  these  processes. 

2.  The  KWS  Data  Structures 

The  KMS  utilizes,  for  the  most  part,  just  four 
structures  defined  in  the  interface.  It,  naturally, 
requires  access  to  the  SQL  input  reqyest  and  ABDL  output 
request  structures  discussed  in  Chapter  II,  the  rel_req_infa 
and  ab^req_info  structures,  respectively.  However,  the  four 

•  Z  « 

data  structures  to  be  discussed  here  are  only  those  unique 
to  the  KMS. 

The  first  of  these,  shown  in  Figure  12,  is  a  record 
that  contains  information  accumulated  by  the  KMS  during  the 
grammar — driven  parse  that  is  not  of  immediate  use.  This 
record  allows  the  information  to  be  saved  until  a  point  in 
the  parsing  process  where  it  can  be  utilized  in  the 
appropriate  portion  of  the  translation  process.  The  first 
field  in  this  record,  first_tgt,  is  a  pointer  to  the  head  of 
a  list  of  attribute  names.  These  are  the  attribute  names 
specified  by  the  user  request  to  retrieve  information  from, 
or  insert  information  into,  the  database.  This  list  is  only 
utilized  during  SELECT  or  INSERT  operations.  The  second 
field,  templates,  is  also  a  record  and  holds  the  relation 
name(s)  referenced  in  the  user  query.  During  join 
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invokad  when  such  structures  are  recognized,  and  a  low-level 
input  routine,  YACC  generates  a  program  that  syntactically 
recognizes  the  input  language  and  allows  invocation  o-f  the 
user's  code  throughout  this  recognition  process.  The  class 
o-f  speci-fi cations  accepted  is  a  very  general  one:  LALR(l) 
graumnars.  It  is  important  to  note  that  the  user's  code  we 
speak  o-f  .  here  is  our  mapping  code  that  is  going  to  perform 
the  SQL-to— ABDL  translation.  As  9 the  low— lev»l  input 
routine,  we  have  utilized  a  Lexical  Analyzer  Qenerator  (LEX) 
CRef.  161.  LEX  is  a  program  generator  designed  for  lexical 
processing  of  input  character  streams.  Given  a  regular- 
expression  description  of  the  input  strings,  LEX  generates  a 
program  that  partitions  the  input  stream  into  tokens  and 
communicates  these  tokens  to  the  parser. 

The  parser  produced  by  YACC  consists  of  a  finite- 
state  automaton  with  a  stack  and  performs  a  top-down  parse, 
with  1 ef t-to-right  scan  and  one  token  look-ahead.  Control 
of  the  parser  begins  initially  with  the  highest-level 
grammar  rule.  Control  descends  through  the  grammar 
hierarchy,  calling  lower  and  lower — level  grammar  rules  which 
search  for  appropriate  tokens  in  the  input.  As  the 
appropriate  tokens  are  recognized,  some  portions  of  the 
mapping  code  may  be  invoked  directly.  In  other  cases,  these 
tokens  are  propagated  back  up  the  grammar  hierarchy  until  a 
higher — level  rule  has  been  satisfied,  at  which  time  further 
translation  is  accomplished.  When  all  of  the  necessary 


IV.  IHg  KERNEL  MAPPINB  SYSTEM  (KJIS) 


The  KMS  is  the  second  module  in  the  SQL  mapping 
inter-face  and  is  called  -from  the  language  interface  layer 
(LID  when  the  LIL  has  received  SQL  input  requests  from  the 
user.  The  function  of  the  KMS  is  to:  (1)  parse  the  request 
to  validate  the  user's  SQL  syntax ,  4nd  (2)  translate,  or 
ma^,  the  request  to  an  equivalent -’ABDL  request.  Once  an 
appropriate  ABDL  request,  or  set  of  requests,  has  been 
formed,  it  as.made  .aveilable  to  the  kernel  controller  (KC) 
which  then  processes  the  request  for  execution  by  MBOS.  The 
KC  is  to  be  discussed  in  Chapter  V. 

A.  AN  OVERVIEW  OF  THE  MAPPING  PROCESS 

From  the  description  of  the  KMS  functions  above  we 
immediately  see  the  requirement  for  a  parser  as  a  part  of 
the  KMS.  This  parser  validates  the  SQL  syntax  of  the  input 
request.  It  is  the  driving  force  behind  the  entire  mapping 
system. 

1 .  The  KMS  Parser  /  Translator 

The  KMS  parser  has  been  constructed  by  utilizing 
Yet-Another — Compiler  Compiler  (YACC)  CRef.  153.  YACC  is  a 
program  generator  designed  for  syntactic  processing  of  token 
input  streams.  Given  a  specification  of  the  input  language 
structure  (a  set  of  grammar  rules),  the  user's  code  to  be 


mfNiiary  occupiad  by  th*  us*r  data  structura  is  -fread  up  and 
raturnad  to  tha  oparating  systa«n.  Sinca  all  o-f  tha  usar 
structuras  rasida  in  a  list,  tha  ax i ting  usar's  noda  must 
ba  ramovad  from  tha  list. 

B.  SHORTCOniNGS 

As  usad  in  this  chaptar,  a  transaction  consists  o-f  a 

singla  raquast  on  a  databasa.  A  transaction  would  normally 

% 

ba  ^allowad  to  contain  multi pi a  raquasts,  such  as  an 

t 

insart,  a  quary,  and  than  a  modify  on  soma  portion  of  a 
databasa.  This  featura  is  not  incorporated  into  the 
present  system,''  but'  it  could  be  easily  integrated  at  some 
later  date. 


46 


Pick  th«  nufflbsr  or  letter  o-f  the  action  desired 

(nufli)  -  execute  one  o-f  the  preceding  queries 
(d)  -  redisplay  the  list  o-f  queries 

(x)  ~  return  to  the  previous  menu 

ACTION  - > 

Since  queries  are  independent  itemSf  the  order  in  which 
they  are  processed  does  not  matter.  The  user  has  the 
choice  o-f  executing  any  number  o-f  queries.  A  loop  causes 
the  query  listing  and  menu  to  te  redisplayed  a-fter  any 
query  has  been  executed  so  that  -further  choices  may  made. 

d.  Calling  the  KC 

As  mentioned  be-fore,  the  LIL  acts  as  the 
control  module  for  the  entire  system.  Mhen  the  KMS  has 
completed  its  mapping  process,  the  transformed 
transactions  must  be  sent  to  the  KC  to  interface  to  the 
kernel  database  system.  For  creates  the  KC  is  called 

after  all  creates  on  the  transaction  list  have  been  sent 

to  the  KMS.  The  mapped  creates  reside  in  another  list 

that  the  KC  is  going  to  access.  Since  queries  are 
independent  items,  the  user  should  wait  for  the  results  from 
one  query  before  issuing  another  query.  Therefore,  after 
each  query  has  been  sent  to  the  KMS,  the  KC  is  immediately 
called.  The  single  mapped  query  resides  on  the  same  second 
list  for  the  creates  which  the  KC  can  access  easily. 

e.  Wrapping-up 

Before  exiting  the  system,  the  user  data 

structure  described  in  Chapter  II  must  be  deallocated.  The 
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pointed  to  by  the  request  pointer,  curr_req,  of  the  data 
structure,  tran^in-fo.  (See  Figure  10  again.)  There-fore,  it 


is  the  Job  of  the  LIL  to  set  this  pointer  to  the 
correct  transaction  be-fore  calling  the  KMS. 

(1)  Sending  Creates  to  the  KMS.  When  the  user 
has  specified  the  -filename  o-f  creates  (if  the  input  is  from 
a  file)  or  typed  in  a  set  of  creates  (if  the  input  is  from 
the  terminal),  any  further  use^  intervention-  is  not 
required.  To  produce  a  new  database,  it  does  not  make  sense 
to  process  only  a  single  create  out  of  a  set  of  creates, 
since  they  all  must  be  processed  in  a  specific  order. 
Therefore,  the  transaction  list  of  creates  is  sent  to  the 
KMS  in  its  entirety.  A  program  loop  traverses  the 
transaction  list,  calling  the  KMS  for  each  create  in  the 
list. 

(2)  Sendi ng  Queries  to  ^he  KMS.  In  this 
case,  after  the  user  has  specified  his  mode  of  input, 
he  conducts  an  interactive  session  with  the  system.  First, 
all  queries  are  listed  on  the  screen.  As  the  queries  are 
listed  from  the  transaction  list,  a  number  is  assigned  to 
each  query  in  ascending  order,  starting  with  the  number  one. 
The  number  is  printed  on  the  screen  to  the  left  of  the 
first  line  of  each  query.  Next,  an  access  menu  is 


displayed  which  looks  like  the  following: 


This  input  nay  conn  -From  a  data  fils  or  intsracti vely  from 
the  terminal.  The  generic  menu  looks  like  the  following: 

Enter  mods  of  input  desired 

(f)  -  read  in  a  group  of  transactions  from  a  file 
(t)  -  read  in  transactions  from  the  terminal 
(x)  -  return  to  the  previous  menu 

ACTION  - > 

Again,  each  mode  of  input  picked  corresponds  to  a 

different  procedure  to  be  performed.  The  transaction  list 
•  • 
is  created  by  reading  from  the  file  or  terminal 

looking  for  an  end— of —transaction  marker  or  an  end-of- 

f ile  marker.  *  These  'flags  tell  the  system  when  one 

transaction  has  ended  and  when  the  next  transaction 

begins.  When  the  list  is  being  created,  the  pointers  to 

access  the  list  must  be  initialized.  These  pointers, 

first^req  and  curr_req,  have  been  described  earlier  in  the 

data  structure  section.  Both  pointers  are  set  to  the 

first  transaction  read,  in  other  words,  the  head  of  the 

transaction  list. 

c.  Accessing  the  Transaction  List 

Since  the  transaction  list  stores  both  creates 
and  queries,  two  different  access  methods  must  be 
employed  to  send  the  two  types  of  transactions  to  the 
KtlS.  We  discuss  the  two  methods  separately.  In  both 

cases  the  KMS  accesses  a  single  transaction  from  the 


transaction  list. 


It  does  this  by  reading  the  transaction 


control  -for  each  user  o-f  the  system.  When  a  user  logs  onto 


the  system,  a  user  data  structure  is  allocated  and 
initialized.  The  user  ID  becomes  the  distinguishing 
feature  to  locate  and  identify  different  users.  The 
user  data  structures  for  all  users  are  stored  on  a  linked 

I 

list  so  that  when  a  new  user  enters  the  system,  their 
initialized  user  data  structure  is  appended  to  the  end  of' 
the  list.  In  our  current  environment  there  is  only  a  single 
I  element  on  the  user  list.  In  a  future  environment,  when 

there  are  multiple  users,  we  simply  adopt  the  append 
operation  mentioned  above. 

‘b.  Creating  the  Transaction  List 

There  are  two  operations  the  user  can 

perform  on  the  database  schemas.  A  user  can  create  a 
i  new  database  or  process  queries  against  an  existing 

database.  The  first  menu  that  is  displayed  prompts  the 
user  for  which  function  to  perform.  Each  function 

I  represents  a  separate  procedure  to  handle  the  specific 

circumstances.  This  menu  looks  like  the  following: 

Enter  type  of  operation  desired 
(1)  -  load  a  new  database 
(p)  -  process  old  database 
<x)  -  return  to  the  operating  system 

ACTION  - > 

t 

For  either  choice  ii.e. ,  1  or  p) ,  another  menu 


is  displayed  to  the  user  asking  for  the  mode  of  input. 


occupiBS.  It  is  ussd  to  allocate  the  correct  and 
ainimal  amount  o-f  memary  space  -for  the  transaction.  The 
last  field,  next_req,  is  a  pointer  to  the  next  transaction 
structure  rel_req_inf o,  in  the  transaction  list. 


2.  Procedures  and  Functions 

The  LIL  makes  use  of  a  number  of  procedures  and 
functions  in  order  to  create  the  transaction  list,  pass 
elements  of  the  list  to  the  KMS,  aAd  maintain  the-'  database 
sciTemas.  Each  of  these  procedures  .-and  functions  Mill  not 
be  described  in  detail,  but  a  general  description  of  the 
LIL  process  will  be  discussed, 
a.  Initialization 

The  MLDS  is  designed  to  be  able  to  accommodate 
multiple  users,  but  is  implemented  to  support  only  a  single 
user.  To  facilitate  the  transition  from  a  single-user 
system  to  a  multiple  user  system,  each  user  possesses  his 
own  copy  of  a  user  data  structure  when  entering  the 
system.  This  user  data  structure  stores  all  of  the 
relevant  data  that  the  user  may  need  during  their  session. 
All  four  modules  of  the  mapping  process  make  use  of  this 
structure.  The  modules  use  many  temporary  storage 
variables  in  performing  their  tasks  or  for  passing  data 
between  modules.  The  transactions,  in  user  data 
language  and  mapped  kernel  data  language  form,  are  also 
stored  in  each  user  data  structure.  It  is  easy  to  see 


that  the  user  structure  provides  consolidated. 


central ized 


e^drass  o-f  tha  t.ranaaction  currantly  baing  processed. 

The  L-IL  sets  this  pointer  to  the  transaction  that  the  KMS 

will  next  process,  and  then  calls  KMS.  The  third  -field, 

no_req,  contains  the  number  o-f  transactions  currently  in 

the  transaction  list.  This  number  is  used  -for  loop 

control  when  printing  the  transaction  list  to  the  screen  or 

when  searching  the  list  -for  a  transaction  to  be  executed. 

The  second  data  structure  ^sed  by  LIL  is  named 

rer^req_in-f o.  Each  copy  o-f  this  .structure  represents  a 

user  transaction  and  thus,  is  an  element  o-f  the 

transaction  list.  The  rel_req_in-f o  is  given  in  Figure  11. 

The  -first  field  of  this  record,  req,  is  a  character  string 

that  contains  the  actual  SQL  transaction.  The  second 

field,  in_req,  is  a  pointer  to  a  list  of  character  arrays 

that  each  contain  a  single  line  o.f  one  transaction. 

After  all  lines  of  a  transaction  have  been  read,  the 

line  list  is  concatenated  to  form  the  actual 

transaction,  req.  The  third  field  of  this  structure, 

req_len,  contains  the  number  of  characters  the  transaction 

struct  rel  req  info 

char  *req; 

struct  temp_str_inf o  *in_req; 

int  req_len; 

struct  rel_req_info  ■♦next  req; 

y 

Figure  11.  The  rel_req_info  Data  Structure. 


a.  Tha  SQL  SELECT  to  tha  ABOL  RETRIEVE 

A  simpla  SQL  SELECT  construct  is  mappad  to  a 
single  ABDL  RETRIEVE  construct.  A  simpla  SELECT  is 
characterized  as  a  SELECT-FROli— WHERE  block,  in  which  access 
is  limited  to  the  in-Formation  contained  in  a  single  relation 
of  the  database.  The  SELECT-clause  may  contain  attribute 
names  alone,  or  the  aggregate  functions  (COUNT,  SUM,  AVG, 
MAX,  and  MINI  may  be  applied  to  any  bf  the  attributes  where 
it 'makes  sense  to  do  so.  The  SELECT— gl ause  may  also  contain 
an  asterisk  (») ,  which  signifies  that  all  attributes  in  the 
relation  should  be  retrieved,  in  lieu  of  ah  exhaustive 
listing.  As  a  final  option,  the  attribute  names  may  be 
prefixed  with  the  relation  name  (rel_name. attr^name) ,  even 
though  only  a  single  relation  is  being  accessed.  The  FROM- 
clause  contains  this  single  relation  name.  The  WHERE-clause 
may  contain  any  number  of  predicates  connected  together  by 
the  boolean  operators  (AND  and  0R> .  Each  predicate  may 
utilize  the  six  standard  relational  operators  (=,  /=,  >,  >=, 
<,  and  <=)  to  separate  the  attribute  name  and  value,  or  the 
set  membership  operators  (IN,  NOT  IN,  /=ANY,  <=ANY,  <ANY, 
>ANY,  >=ANY,  <=ALL,  <ALL,  >ALL,  >=ALL)  may  be  used  to 
separate  the  attribute  name  from  an  enumerated  set  of 
values.  Finally,  the  SELECT-FROM-WHERE  block  may  be 
optionally  followed  by  either  a  GROUP  BY-clause,  or  an  ORDER 
BY-clause,  whereby  retrieved  attributes  may  be  either 


grouped  or  sorted. 


A  nested  SQL  SELECT  construct  is  mapped  to  a 
series  o-f  ABDL  RETRIEVE  constructs.  A  nested  SELECT  is 
characterized  as  a  SELECT -FROM— WHERE  block,  in  which  the 
WHERE— clause  utilizes  one  o-f  the  set  membership  operators. 
In  this  instance,  however,  the  operator  is  -followed  by 
another  complete  SELECT-FROli-WHERE  block  instead  o-f  an 
enumerated  set  o-f  values.  Such  constructs  can  be  nested  to 
any  depth.  This  allows  multiple  relations  to  be  accessed, 
and'  their  attribute— values  compared*  while  the  values 
returned  to  the  user  are  taken  from  only  a  single  relation. 
This  is  analogous  to  an  implicit  Join  operation.  An  example 
of  such  a  query  is  as  follows:  Note  that  the  parentheses  are 
optional  and  need  not  be  included. 

SELECT  name,  age 
FROM  student 
WHERE  name  IN 

(  SELECT  name 

FROM  faculty  > 

This  query  would  find  the  name  and  age  of  all  students  who 
are  also  a  member  of  the  faculty.  It's  ABDL  counterparts 
would  be  as  follows: 

C  RETRIEVE  (TEMPLATE  =  FACULTY)  (NAME)  3 

Z  RETRIEVE  ( (TEMPLATE  =  STUDENT)  and 

(NAME  =  ***********))  (NAME,  AGE)  3 


Notice  that  the  first  ABDL  request  corresponds  to  the  last 
(or  innermost)  SQL  request.  This  is  because  the  innermost 
SQL  request  is  the  only  one  that  represents  a  completely 
specified  simple  SELECT.  The  results  of  the  first  RETRIEVE 
are  names  which  are  used  by  the  KC  to  fill  in  the  place 
holders  marked  with  asterisks  in  the  second  RETRIEVE  (the 
number  of  asterisks  equals  the  maximum  length  of  the  NAME 
attribute—value) .  From  a  single  f nested  SELECT,  the  KMS 
gei^erates  a  series  of  ABDL  RETRIEVES.-  before  relinquishing 
control  to  the  KC,  for  subsequent  execution  of  the  ABDL 
requests. 

A  join  SQL  SELECT  construct  is  mapped  to  a 
single  ABDL  RETRIEVE-COMMON  construct.  A  join  SELECT  is 
characterized  as  a  SELECT -FROM— WHERE  block,  in  which  the 
FROM-clause  contains  two  relation  names.  We  have  already 
seen  how  the  nested  SELECT  query  specifies  an  implicit  join. 
Here  we  are  concerned  with  explicit  joins,  where  multiple 
tables  are  accessed,  and  their  attribute  values  compared, 
with  the  values  returned  to  the  user  being  taken  from  two 
different  relations.  In  this  instance,  the  SELECT-cl ause 
normally  contains  attri bute— names  that  are  prefixed  with  the 
appropriate  relation  name  (rBl_name. attr_name) .  This 
eliminates  any  ambiguity  that  might  otherwise  exist.  The 
prefixed  attribute-names  are  a  required  convention  in  the 
WHERE-clause.  An  example  of  such  a  query  is  as  fallows: 


SELECT  student. name,  faculty. name 

FROM  student,  faculty 

WHERE  student. cl ass  •  faculty. cl ass 

Assuming  each  class  was  only  taught  by  one  member  of  the 
faculty,  this  query  would  return  a  class  roster  for  all 
members  of  the  faculty.  It's  ABDL  counterpart  would  be  as 
follows: 

C  RETRIEVE  (TEMPLATE  »  STUDENT)  (NAME) 

COMMON  (CLASS  »  CLASS) 

RETRIEVE  (TEMPLATE  »  FACULTY)  (NAME)  1 

Notice  the  placement  of  the  square  brackets  around  the  ABDL 
request.  This  represents  a  single  ABDL  request,  and  is 
forwarded  to  MBDS  for  execution  as  a  single  transaction. 
The  use  of  prefixed  attribute  names  in  the  SELECT-cl ause  is 
not  a  necessity,  providing  that  the  attribute-names  used  are 
valid  in  both  relations.  Thus,  the  last  SQL  example  may  be 
entered  as  shown  below  to  obtain  the  same  results. 

SELECT  name 

FROM  student,  faculty 

WHERE  student . class  =  faculty. class 

b.  The  SQL  INSERT  to  the  ABDL  INSERT 

The  SQL  INSERT  construct  is  mapped  to  a  single 
ABDL  INSERT  construct.  If  values  are  to  be  inserted  for 


IS 


■ach  attributa  in  tha  ralation,  thara  is  no  requirament  to 
list  the  attribute  names.  Only  the  attribute  values  need  be 
listed;  however,  they  must  appear  in  the  correct  order  (as 
listed  in  the  schema  which  has  baen  determined  during  the 
original  database  de-finition  o4  the  relation).  If  values 
are  not  inserted  for  each  attribute  in  the  relation, 
corresponding  attribute  names  of  those  attribute  values  to 
be  inserted  must  also  be  included  inf  the  request. 

c.  The  SQL  UPDATE  to  the  ABDL  UPDATE 

The  SQL  UPDATE  construct  is  mapped  to  a  single 
ABDL  UPDATE  construct.  ABDL  does  not  provide  a  single- 
request  construct  which  updates  more  than  one  attribute  in  a 
record.  Thus,  we  only  allow  one  predicate  in  the  SET-clause 
of  the  SQL  UPDATE  query.  However,  the  attribute  value  in 
this  predicate  may  be  a  constant,  or  an  arithmetic 
expression  based  on  the  original  value  of  the  attribute. 

d.  From  the  SQL  DELETE  to  the  ABDL  DELETE:  An 

Ex  amp 1 e 

The  SQL  DELETE  construct  is  mapped  to  a  single 
ABDL  DELETE  construct.  The  SQL  DELETE  may  have  an  optional 
WHERE-clause,  so  that  all  records  for  the  particular 
relation  may  be  deleted  when  the  WHERE-clause  is  empty,  or 
only  those  records  satisfying  a  specific  condition  may  be 
deleted  when  the  WHERE-clause  is  included.  In  this 


subsection  we  will  present  an  illustrative  example  of  the 
mapping  process  for  a  simple  SQL  DELETE  request.  We  begin 


by  showing  ths  graimnar  -for  ths  dalete-portion  o-f  ths  KMS. 
Ms  than  stop  through  the  gr-tminar  and  show  appropriate 
portions  o-f  our  design  in  System  Specification  Language 
(SSL).  The  entire  design  is  shown  in  Appendix  C.  The 
relevant  grammar  is  as  follows: 

delation  :  DELETE  tabla.name  E; 

table.name  :  IDENTIFIER;* 

E  :  empty 

!  WHERE  boolean; 

empty  :  ; 

boolean  :  *  ...  ; 

The  source  SQL  request  we  will  utilize  for  our  example  will 
be  the  following: 

DELETE  student 

It's  ABDL  translation  will  be  as  follows: 

C  DELETE  (  TEMPLATE  =  STUDENT)  ] 

To  begin  our  discussion,  let  us  first 
synchronize  the  reader.  At  the  beginning  of  a  mapping 
process,  the  parse  descends  the  grammar  hierarchy  searching 
for  appropriate  tokens  in  the  source  that  may  satisfy  one  of 
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the  grammar  rules.  Thus,  the  parser  descends  through  the 
rules  -For  SELECTS,  INSERTS,  etc.  A-fter  -finding  no  matching 
tokens  -for  those  rules,  the  parser  eventually  descends  on 
the  DELETE  rules. 

First,  when  the  deletion  rule  is  called,  the 
OELETE-token  will  be  recognized.  In  an  attempt  to  satisfy 
the  deletion  rule,  the  table_name  rule  is  then  called.  The 
table_name  rule  recognizes  the  ISENTIFIER-token^^,  as  the 
STSDENT'token  (student  converted  to  upper — case  upon  input) . 
At  this  time,  the  table_name— rule  is  completely  satisfied, 
and  the  following  SSL  is  invoked: 

table_name  :  IDENTIFIER 

<. 

if  (!  creating) 

if  (!  vali datable ( 'table.name ' )  ) 
print  ("Error  -  rBl_name  not  valid") 
perform  yyerror ( ) 
return 
end_if 
end  if 
1; 

If  we  are  not  creating  a  new  database  (as  in  this  case),  a 
call  is  made  to  the  val i d_table ( )  function,  which  checks  the 
validity  of  the  IDENTIFIER  table_name  in  the  relational 
database  schema.  If  STUDENT  is  not  a  valid  relation  name, 
then  an  error  message  is  printed,  and  an  error  routine  is 
called.  Then  we  simply  return  from  the  mapping  process.  If 
STUDENT  is  a  valid  relation  name,  there  i s  no  code  here  for 
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translation;  howavsr,  control  rsturns  to  the  rule  that 
called  the  table.name  rule  (i.e. ,  the. deletion  rule). 

Next,  even  though  the  deletion  rule  is  not 
completely  satisfied,  we  need  to  perform  some  translation. 
The  following  SSL  is  invoked,  before  the  call  is  made  to  the 
E—rule: 

deletion  :  DELETE  table_naffle 
f 

'  copy  '*C  DELETE  <  '*  ,•  to  abdl_string 

copy  'table_name'  to  templates 

> 

E; 

The  abdl_string  begins  to  be  built,  as  we  initially  copy 

"C  DELETE  (  '• 

into  the  abdl_string.  The  value  of  the  table_name  (STUDENT) 
is  then  copied  to  the  templates  data  structure,  because,  at 
this  point,  we  are  not  certain  that  it  is  of  immediate  use. 
The  reader  should  note  the  trailing  blank  that  we  placed  in 
the  abdl_string.  Without  going  into  great  detail,  which  is 
beyond  the  scope  of  this  example,  it  suffices  to  say  that 
this  blank  is  for  an  additional  left  parenthesis  that  we  may 
later  determine  to  be  required  at  the  beginning  of  the  ABDL 
request,  i.e.,  when  OR  is  used  to  connect  WHERE-clause 
predicates. 
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Th«  n*xt  st*p  in  th»  p«rs«  is  for  the  deletion 
rule  to  call  the  E— rule.  The  E-rule  recognizes  the  empty 
rule,  because  the  source  is  now  void  of  additional  tokens. 
The  E-rule  is  now  completely  satisfied  and  the  following  SSL 
is  invoked: 


E  :  empty 

< 

delete.all  »  rRUE 

> 

I  WHERE  boolean; 


This  sets  the  delete.all  boolean  variable  equal  to  true. 
Control  now  reverts  to  the  deletion  rule,  which  is  of  course 
completely  satisfied.  Thus,  the  following  SSL  is  invoked: 


deletion  :  DELETE  table  name 
E 

i 

if  (delete.all) 

concat  "TEMPLATE  =  '  table.name  ' 

to  abdl.string 

end. if 

concat  ")"  to  abdl  string 

3; 

Since  we  know  that  the  delete.all  variable  has  previously 
been  set  to  true,  we  now  concatenate 


"TEMPLATE  »  STUDENT" 


to  the  abdl.string.  Finally,  we  concatenate  the  trailing 


right  parenthesis  to  the  abdl_string.  The  trailing  right 
bracket  (3)  is  concatenated  to  the  abdl_string  a-fter 
recognition  of  a  higher — level  graflimar  rule  (one  that  called 
the  deletion— rule) ,  and  the  mapping  process  is  now  complete. 

Let  us  continue  with  an  extension  of  this 
example.  Had  the  original  SQL  source  request  included  s 
WHERE  boolean-clause,  such  as  the  following,  what  would  have 
happened? 


DELETE  student 
WHERE  name  =  'Jones' 

*  C  '  » 

Its  ABDL  equivalent  is  as  follows: 

C  DELETE  (  (TEMPLATE  =*  STUDENT)  and  (NAME  =  Jones))  1 

In  this  instance,  when  the  E  rule  is  called,  the  WHERE-token 
would  have  been  recognized,  and  thus  the  boolean  rule  would 
have  been  called.  The  boolean  rule  would  have  called  other 
rules  and  continued  to  read  the  /remainder  o-f  the  input 
(source)  tokens.  Before  the. boolean  rule  was  called,  the 
abdl_string  contained  the  following: 

"C  DELETE  ( 


When  control  returns  to  the  E— rule,  from  the  boolean  rule, 


th«  abdl_string  will  contain  the  -following: 

"C  DELETE  <  (TEMPLATE  =  STUDENT)  and  (NAME  =»  Jones)" 

Than  control  would  revert  from  the  E— rule  to  the  deletion 
rule.  But  this  time,  since  the  delete_all  variable  is  not 
set  to  true  in  the  E-rule,  the  deletion  rule  merely 
completes  this  portion  o-f  the  translation  by  concatenating 
anther  right  parenthesis  to  the  abd^_string  shown  above. 
Again,  the  trailing  right  bracket  is  added  at  a  higher 
level,  and  the  mapping  process  is  complete. 

C.  FACILITIES  NOT  PROVIDED  BY  THE  IMPLEMENTATION 

Our  original  intent  has  been  to  demonstrate  that  the 
relational  inter-face  could  indeed  be  developed  and 
implemented.  As  a  demonstration,  there  are  some  facilities 
that  are  not  included  in  our  implementation.  Some  of  these 
facilities  have  more  to  do  with  providing  a  user-friendly 
environment,  than  with  supporting  a  germane  relational 
interface.  For  others,  the  programming  time  and  effort 
required  to  incorporate  them  would  be  too  costly  for  the 
benefits  derived.  However,  this  is  not  to  imply  that  such 
facilities  would  not  be  useful.  This  section  is  devoted  to 
describing  the  most  prominent  features  of  SQL  that  are  not 
supported  by  the  language  interface. 
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1 .  Inter -facing  Users 

In  our  relational  interface,  there  is  no  concept  of 
a  user  view.  A  view  may  be  thought  of  as  a  virtual  relation 
that  has  no  existence  in  its  own  right,  but  is  derived  from 
one  or  more  existing  relations.  Under  our  implementation, 
the  logical  database  and  the  physical  database  are  one  in 
the  same.  Thus,  our  interface  is  limited  to  data  definition 
language  (ODD  and  data  manipulation  language  (DML) 
stiitements,  and  provides  no  data-con-tirol  facilities  such  as 
the  GRANT  and  REVOKE  options.  Also,  all  CREATE  TABLE 
requests  are  considered  PERMANENT  and  SHARED.  As  mentioned 
in  Chapter  II,  our  interface  data  structures  are  constructed 
to  facilitate  future  use  by  multiple  users.  This  would 
allow  the  view  concept  to  be  supported  by  incorporating  the 
relational  database  schemas  into  the  user_inf ormati on 
structure  (user_info  shown  in  Figure  7) .  These  schemas 
would  be  virtual  and  user — specific  with  respect  to  the 
entire  list  of  database  schemas  that  are  still  global. 

2.  UEdating  Mul.ti.Bl.e  Attributes 

ABOL  does  not  provide  a  si ngl e— request  construct 
which  updates  more  than  one  attribute  in  a  record.  The  work 
of  Rollins  CRef.  3:  pp.  25-271  has  showed  that  the  SQL 
UPDATE  may  be  translated  into  multiple  ABDL  requests.  As  a 
result,  it  may  be  necessary  to  generate  either  several 
independent  ABDL  UPDATES,  a  transaction  of  ABDL  UPDATES 
(specifying  the  order  in  which  a  series  of  requests  must  be 
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processed) ,  or  an  ABDL  RETRIEVE,  DELETE,  and  INSERT 
sequence,  to  accomplish  the  requested  update  o-f  multiple 
attributes.  We  have  felt  the  programming  effort  involved  to 
provide  such  a  facility,  although  not  complex,  is  time- 
consuming. 

3.  Retrieving  Qualified  Groups 

ABDL  provides  an  option  whereby  retrieved  attributes 
may  be  sorted  (the  by-attribute_namfc  option).  SQL-  provides 
a  fiirther  option  whereby  those  records  not  satisfying  a 
specified  condition  can  then  be  eliminated  (the  HAVING— 
condition  option).  ABDL  does  not  provide  a  facility  for 
checking  this  specified  condition.  It  could  have  been 
implemented  in  the  KC;  however,  we  have  felt  the  programming 
effort  is  too  great  for  the  benefits  derived. 

Retrieving  Cornguted  Values 

This  option  supports  the  inclusion  of  arithmetic 
expressions  involving  attribute  names  in  the  SELECT-cl ause 
of  SQL  requests.  An  example  of  this  option  is  as  follows: 

SELECT  name,  weight  *  454 
FROM  student 

This  query  would  retrieve  the  name  and  weight  of  all 
students.  However,  the  value  of  the  attribute  weight  would 
be  returned  to  the  user  in  grams  (found  in  the  student 
relation  in  pounds).  ABDL  does  not  support  the  retrieval  of 


been  determined  when  the  values  are  loaded  into  the  file)  is 
obtained  for  use  in  the  procedure.  After  seme 
initialization  steps  are  executed  an  inner  loop  is 
encountered.  This  inner  loop  controls  the  actual  building 
and  executing  of  the  current  ABDL  request  template  which 
corresponds  to  one  of  the  outer — level  SQL  selects. 

The  inner  loop  calls  the  procedure  bui 1 d_request  to 
produce  the  next  fully-formed  ABDL  retrieve.  Control  in 
this  procedure  is  branched  based  upon  .which  of  the  eleven 
possible  SQL  operators  is  in  the  current  request.  These 
eleven  possible  SQL  operators  result  in  four  possible 
situations.  For  the  operators  <=ANY,  <ANY,  >=ALL  and  >ALL 
the  procedure  one_con junction  is  called  with  the  maximum 
value  of  the  results  in  the  current  results  file  passed  as  a 
parameter.  (The  maximum  and  minimum  values  were  calculated 
by  the  procedure  f i 1 e^f uture_resul ts  when  the  values  were 
loaded  into  the  f uture— resul ts  file.)  For  the  operators 
>=ANY,  >ANY,  <=ALL  and  <ALL  the  procedure  one_con juncti on  is 
also  called,  this  time  with  the  minimum  value  of  the  results 
in  the  current-results  file  passed  as  a  parameter.  For  the 
IN  and  ~=ANY  operators  the  procedure  n_con juncti on  is 
called.  For  the  NOT  IN  operator  the  procedure 
nQt_i n_con juncti on  is  called.  These  three  conjunction 
procedures  all  produce  one  or  more  fully-formed  ABDL 
retrieves  using  the  request  template.  The  inner  loop  then 
calls  sql_execute  to  process  the  ABDL  retrieve.  The  inner 


then 


requests.  I-F  a  simple  SQL  select  is  being  processed, 
only  one  ABDL  retrieve  is  generated  by  the  KMS.  I-f  an  SQL 
nested-select  is  being  processed,  then  two  or  more  ABDL 
retrieve  requests  are  generated  by  the  KMS.  Only  the  -first 
ABDL  retrieve  for  an  SQL  nested-select  is  a  complete  ABDL 
retrieve.  The  remaining  ABDL  retrieves  are  actually  ABDL 
request  templates.  An  ABDL  request  template  and  the  results 
of  the  previous  retrieve  ar'e  combined  by  the  KC  to  build  the 
fully— formed  ABDL  request.  ,  The  procedure 

select_requests_handler  manages  both  possible  situations. 
.First,  the  procedure  sql^execute  is  called  to  process  the 
initial  fully— formed  ABDL  retrieve  request.  If  this  request 
is  not  an  SQL  nested-select,  no  other  ABDL  request  templates 
remain.  If  ABDL  request  templates  are  left  to  process,  then 
a  loop  is  entered  to  process  these  retrieves.  This  loop  is 
repeatedly  executed  until  all  ABDL  request  templates  have 
been  processed. 

An  overview  of  the  activities  controlled  by  this 
loop  is  necessary  to  understand  how  the  KC  handles  the  SQL 
nested-select.  One  of  the  initial  steps  in  the  loop  is  a 
call  to  the  procedure  swap_files.  This  procedure  obtains 
the  results  generated  by  the  previous  ABDL  request  (which 
are  stored  in  the  f uture— resul ts  file  by  the  procedure 
f i le_f uturB_resul ts)  and  puts  them  into  the  current-results 
file,  where  they  are  used  to  build  the  next  ABDL  retrieve. 
The  number  of  valu-es  in  the  current-results  file  (which  has 


C3^  requests  by  calling  the  procedure  rest_requests_handler 
which  calls  the  procedure  sql_execute.  The  procedure 
sql_e}(ecute  controls  the  submission  o-f  ABDL  requests  to  the 
KDS.  To  control  the  submission  process  the  procedure 
sql_execute  uses  two  TI  procedures  and  the  procedure 
sql_chk_reBponses_le-ft.  In  general,  the  procedure 
sql_execute  sends  the  ABDL  request  to  the  KDS,  waits  -for  the 
last  response  to  be  returned  from  the  KDS  and  then  takes 
action  appropriate  -for  the  type  o-f  request  submitted  and  the 
response  received.  For  any  o-f  the  request  types  sent  to  the 
KDS  an  error  response  might  be  received  back^  In  this 
situation,  an  error  message  is  sent  to  the  user.  I-f  an 
error  response  was  not  received,  then  the  ABDL  request  was 
correctly  processed.  For  insert,  delete  and  update 
requests,  the  user  is  sent  a  message  in-forming  him  that  the 
operation  has  been  success-f ul ly  executed.  For  a  retrieve- 
common  request,  the  results  returned  by  the  KDS  are  sent  to 
the  KFS  for  formatting.  Control  then  returns  upward  through 
the  various  procedures  until  it  reaches  the  LIL. 

4 .  Bst r i.eve  Reguests 

ABDL  retrieve  requests  are  the  other  category 
of  requests  that  the  KC  processes.  The  processing  of 
retrieve  requests  is  more  complex  than  the  other  types  of 
requests,  since  multiple  retrieves  (which  correspond  to  SQL 
nested— sel ects)  may  need  to  be  processed.  The  procedure 
sel ect_requests_handl er  is  called  to  process  ABDL  retrieve 


an  update  request,  the  procedure  rest_request_handler 
is  called.  If  ■  the  transaction  is  a  retrieve 
request,  then  the  procedure  select_requests_handler  is 
called.  If  the  transaction  is  none  of  the  above,  there 
is  an  error.  An  error  message  is  generated  and  control  is 
returned  to  the  LIL. 

2.  The  Creation  of  a  New  Database 

The  creation  of  a  new  database  is  the  least 
difficult  transaction  that  the  KC  bandies.  The  procedure 
load_tables  is  called  by  the  KC  and  performs  two  functions. 
First,  the  test  interface  (TI)  procedure  dbl_template  is 
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called.  This  procedure  is  used  to  load  the  database- 
template  file  created  by  the  KMS.  Next  the  TI  procedure 
dbl_dir_tbls  is  called.  This  procedure  loads  the 
database— descriptor  file.  These  two  files  represent  the 
attribute-based  metadata  that  is  loaded  into  the  KDS,  i.e. , 
MBOS.  After  execution  of  these  two  procedures,  load_tables 
returns  control  back  to  the  kernel _controller  which  in  turn 
returns  control  back  to  the  LIL. 

3.  Insert .  Delete.  UB^ate  and  Retri eve— Common  Reguests 
Insert,  delete,  update  and  retrieve— common  requests 

are  all  handled  in  a  similar  fashion.  For  any  of  these  four 
types  of  requests,  the  KMS  sends  the  translated  ABDL  request 
to  the  KC  for  processing.  The  main  task  of  the  KC  for  these 
four  categories  of  requests  is  to  send  the  ABDL  request  to 
the  KDS  (MBDS)  for  processing.  The  KC  handles  these  types 


typ«  is  subrBq_stat.  This  integer— valued  variable  is  a  -flag 
used  when  the  .  KC  is  handling  a  nested  select.  The  -flag 
is  set  to  indicate  either  that  the  last  subrequest  is 
being  processed  or  an  Intermediate  subrequest  is  being 
processed. 

B.  KC  PROCEDURES  AND  FUNCTIONS 

The  KC  makes  use  o-f  a  number  of  different  procedures 

■  « 

and  functions  to  manage  the  transmission  of  the 

translated  SQL  queries  (i.e. yABDL  requests)  to  the  KDS.  Not 
all  of  these  procedures  and  functions  will  be  discussed  in 
detail.  Instead,  we  hope  to  provide  the  reader  with  an 

overview  of  how  the  KC  controls  the  submission  of  the 

various  t-ypes  of  ABDL  transactions  to  MBDS. 

1 •  Ibfi  Kernel  Controller 

The  procedure  Kernel _Control ler  is  called  whenever 
the  LIL  has  an  ABDL  transaction  for  the  KC  to  process. 
This  procedure  provides  the  master  control  over  all 
other  procedures  used  in  the  KC.  The  first  portion  of 

this  procedure  initializes  global  pointers  that  are 
used  throughout  the  KC.  The  other  portion  of  the  procedure 
is  a  case  statement  which  calls  different  procedures  based 
upon  the  type  of  ABDL  transaction  that  is  being  processed. 
If  a  new  database  is  being  created,  the  procedure 
load_tables  is  called.  If  the  transaction  is  a  retrieve- 
common  request,  an  insert  request,  a  delete  request  or 


ba  storad  back  inta  tha  *req  field  of  ab_req_info.  The 
bag_conJ,  wd_conJ ,  .  beg_as'tari sk  and  end_asterisk  are 
integer  fields  which  store  the  positions  they  describe  in 
the  request  teeplate,  i.e. ,  (unf in_rst) .  The  conjunction  is 
that  portion  of  the  request  template  which  must  be  repeated 
as  many  times  as  necessary  to  hold  the  values  returned 
from  the  previous  inner-level  request.  The  asterisks 
indicate  where  in  that  request  the  attribute-values  must  be 
placed.  The  field  req_len  holds  the  value  of  the  maximum 
size  in  bytes  of  the  fully— farmed  ABDL  request  that  the  KC 
builds  and  sends  to  the  KDS.  The  req_len  is  calculated  by 
the  KC  and  is  used  for  allocating  storage  for  the  fully- 
formed  ABDL  request  which  is  constructed  from  the  request 
template. 

The  req_status  is  a  flag  used  to  indicate  whether  we 
are  processing  the  first  request  or  subsequent  requests. 
Curr_pos  is  an  integer — valued  variable  that  is  used  to 
indicate  our  current  position  in  the  current-request  file 
and  that  marks  which  attribute— value  is  the  next  one  to  be 
inserted  into  the  request  being  constructed.  The  res_len 
is  the  last  field  in  the  record  of  type  kc_rel_info  and  is 
an  integer — valued  variable  which  contains  the  length  of  the 
response  buffer  returned  by  the  MBDS.  This  value  is  used  to 
indicate  when  we  have  completed  our  movement  through  the 
response  buffer. 

The  final  field  used  by  the  KC  in  the  sql_info  record 
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handle  SQL  nested  selects.  The  -future-results  file  holds 
results  from  the  current  retrieve  being  processed  by  liBDS, 
Mhile  the  current-results  file  holds  the  results  from  the 
previous  retrieve  request,  which  are  used  to  build  the 
current  retrieve  request.  The  records  max_info  and 
min_info  are  identical  data  structures.  Both  structures 
allow  for  the  storage  of  a  character  'which  indicates  the 
data  type  of  the  attribute— values,  4.e. ,  integers,-  floating 
poiTit  numbers  or  strings.  Both  structures  also  contain  a 
variant  record  which  is  used  for  the  storage  of  the 
respective  maximum  or  minimum  value  encountered  in  the 
resultant  records.  The  nuffl_values_f f ile  and  num_values_cf i le 
indicate  the  number  of  values  stored  in  the  future  or 
current  results  file,  respectively.  The  record  type  of  files 
is  nsel_rBS_inf o.  The  file  field  contains  two  identical 
records  of  type  file_info.  This  record  stores  a  file 
name  and  a  file  descriptor  used  for  file  manipulation  in 
the  C  programming  language.  One  record  is  for  the 
current-results  file  and  the  other  is  for  the  future- 
results  file. 

The  *unfin_ret  is  a  character  array  used  to  store  the 
request  template  sent  to  the  KC  by  the  KMS.  The  request 
template  that  is  stored  in  the  first  field  of  the 
ab_req_info  record  type  is  loaded  into  unfin_ret.  This 
transfer  of  the  request  template  is  necessary  so  that  the 
fully-formed  ABDL  request  that  is  constructed  by  the  KC  can 
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-foriMtad.  This  storage  bu-f-fer  is  only  used  when  we  are 
processing  SQL  sdlects  which  have  been  mapped  to  ABDL 


retrieves.  The  results  of  the  ABDL  retrievals  are 
loaded  into  the  storage  buffer.  When  the  buffer  is 
filled  the  KF5  is  called.  The  process  of  filling  the 
buffer  and  calling  KFS  is  repeated  by  the  KC  until  all 
results  from  the  retrieval  have  been  processed. 

The  next  field  used  by  the  from  the  sql_infa 
record  type  is  kc^data.  This  field  is  a  variant  record 
which  contains  the  record  type  kc_rel_info.  This  record 
type  holds  all  of  the  information  that  is  unique  to  the  KC. 
This  data  structure  is  shown  in  Figure  IB.  The  field 
file_status  is  a  flag  used  to  indicate  the  status  of  the 
current  and  future  result  files.  Two  files  are  necessary  to 
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Figure  IS.  The  kc_rel 
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info  Data  Structure. 
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♦req; 

rBl_op; 

*nsj<t_rBq; 


struct  'ab_rBq_info 
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struct  ab  ral  in-fo 

y 

Figurs  17.  Tha  ab_r6q_in-fo  Data  Structura. 

Tha  no_raq  tails  the  KC  how  many  requests  are  in  the  linked 
list  o-f  the  ab_req_in-fo  structure.  There  will  normally  only 
be  one  request  in  this  list,  u/iless  an  SQL'  nested 
serect  is  being  processed.  In  that  case,  the  no_req  will 
correspond  to  the  number  o-f  levels  that  there  are  in  the 
nested  select.  The  -first  request  will  always  be  a  -fully- 
formed  ABDL  request,  while  any  additional  requests  will  be 
ABDL  request  templates.  The  requests  or  request  templates 
are  stored,  in  the  ab_req_info  record.  The  -s-req  is  a 
painter  to  a  character  string  which  contains  either  the 
request  or  the  request  template.  The  rBl_op  field 
informs  the  KC  which  type  of  relational  operator  is 
contained  in  the  corresponding  request  or  request 
template.  The  eleven  passible  operators  are  IN,  NOT  IN, 
~=ANY,  «;*ANY,  >=ANY,  <ANY,  >ANY,  <=ALL,  >=ALL,  <ALL  and 
>ALL.  The  •»next_req  is  a  pointer  which  directs  the  KC  to 
the  next  ABDL  request. 

The  next  field  of  sql_infa  that  the  KC  uses  is  kfs_data, 
which  is  a  variant  record  into  which  the  responses 
received  from  MBDS  are  stared.  From  this  storage  buffer 
the  KFS  extracts  the  data  returned  from  the  KDS  to  be 
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interacting  with  MBDS.  Whan  tha  KC  sands  an  ABDL 
transaction  to  MBDS  for  execution,  tha  currant  database 
name  must  be  sent  with  the  request.  The  current  database 
name  is  stored  in  the  curr^db  record. 

The  next  field  of  the  sql_info  record  type  which  the  KC 
uses  is  operation.  This  fourth  field  of  sql.info  contains 
an  integer  that  tells  the  KC  what  type  of  operation  is  to  be 
performed.  There  are  six  possibly  types  of  operations 
which  correspond  to  the  six  operations  supported  by  the  KC. 
These  operations  are  a  database  creation  request,  a  retrieve 
request,  a  retrieve—common  request,  a  delete  request,  an 
insert  request  and  an  update  request. 

The  next  field  used  by  the  KC  is  abdl_tran,  which  is  a 
record  of  type  tran_info,  and  is  shown  in  Figure  16.  The 
first  two  fields  of  tran_info  are  variant  records  which 
store  information  on  ABDL  requests.  The  ABDL  requests  are 
stored  in  a  record  of  type  ab_rBq_info,  shown  in  Figure  17. 
Both  first^req  and  curr_req  initially  contain  the  first  ABDL 
request  which  is  loaded  into  the  data  structure  by  the  KliS. 


struct  tran_info 
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Figure  16.  The  tran  info  Data  Structure. 


First  we 


the  KC.  This  discussion  is  in  two  parts, 
examine  the  data  structures  relevant  to  the  KC,  which  is 
■followed,  by  an  examination  O'f  the  procedures  and  -functions 
found  in  the  KC.  Appendix  D  contains  the  design  of 

our  KC  implementation,  written  in  a  system  specification 
language. 

A.  AN  OVERVIEW  OF  THE  KC  DATA  STRUCTURES 

f 

In  this  section  we  will  review  the  data  structures 
mentioned  in  chapter  2,  focusing  on  those  structures  that 
are  accessed  and  used  by  the  KC.  The  first  data  structure 
that  is  important  -to  the  KC  is  the  record  type  sql_info 
shown  in  Figure  15.  The  fields  of  3ql_info  contain  all 
of  the  data  structures  relevant  to  the  KC,  but  the  KC 
only  uses  several  of  the  fields.  The  first’  field  of  this 
record,  curr_db,  is  a  record  which  is  used  by  the  KC  when 

struct  sql_info 


struct 

curr_db_inf o 

curr_db; 

struct 

f ile_info 

fileT 

struct 

tran_inf o 

sql _tran; 

int 

operation; 

struct 

tran_inf o 

♦abdl _tran; 

int 

answer ; 

union 

kms_inf o 

kms_data; 

uni  on 

kf s_inf o 

kf s_data; 

union 

kc_inf o 

kc_data; 

int 

error; 

int 

subreq_stat ; 

Figure  IS.  The  sql  info  Data  Structure. 


Only  th«  -first  ABDL  retrieve  (which  corresponds,  to  the 
innermost  select)  is  a  -fully-formed  request.  All  other 
ABOL  retrieves  which  correspond  to  the  outer-level  selects 
are  sent  to  the  KC  by  the  KliS  as  request  templates.  A 
request  template  is  an  ABDL  retrieve  request  with  one 
unspecified  attribute  value.  The  KC  must  use  the  results 
obtained  from  the  previous  ABDL  retrieve  request  (i.e., 
attribute  values)  and  the  request  template  to  build  the 
ne9t^  ABDL  request,  i.e.,  the  KC  sul^stitutes  the  retrieved 
attribute  values  for  the  unspecified  attribute  value  in  the 
request  template.  The  processing  of  nested  selects  is 
managed  by  the  KC. 

The  procedures  that  make  up  the  interface  to  the  KDS 
(i.e.,  MBDS)  are  contained  in  the  teat  interface  (TI) 
CRef.  81.  To  fully  integrate  the  KC  with  the  KDS  (i.e., 
MBDS),  the  KC  calls  procedures  which  are  defined  in  the  TI. 
Due  to  upcoming  hardware  changes  in  the  MBDS,  we  decide 
not  to  test  the  KC  on-line  with  the  TI.  Our  solution 
to  this  problem  is  to  design  the  system  exactly  as  if  it 
is  interfacing  with  the  TI.  However,  for  each  call  to  a 
TI  procedure  we  create  a  procedure  stub  that  performs  the 
same  function  as  the  actual  TI  procedure.  The  reader 
should  realize  that  all  interactions  with  the  TI  procedures 
described  in  the  KC  are  actually  made  with  these  procedure 
stubs,  rather  than  with  the  on-line  TI  procedures. 

In  this  section  we  discuss  the  processes  performed  by 


V-  IHE  KERNEL  CONTROLLER 


The  kernel  controller  <KC)  is  the  third  module  in  the 
SQL  language  interface  and  is  called  by  the  language 
interface  layer  (LID  when  a  new  database  is  being  created 
or  when  an  ei<i sting  database  is  being  manipulated.  In 
either  situation  the  LIL  first  cal^s  the  kernel-  mapping 
system  (KMS)  which  performs  the  necessary  SQL  to  ABDL 
translations.  Then  the  KC  is  called  to  perform  the  task  of 
controlling  the  submission  of  the  ABDL  transaction (s)  to  the 
multi-backend  database  system  <MBDS)  for  processing.  If  the 
transaction  involves  creating  a  new  database  or 
inserting,  deleting  or  updating  information  in  an  existing 
database,  control  is  returned  to  the  LIL  after  MBDS 
processes  the  transaction.  If  the  transaction  involves  a 
retrieval  request,  the  KC  sends  the  translated  ABDL  request 
to  NBDS,  receives  the  results  back  from  liBDS,  loads  the 
results  into  a  buffer  and  calls  the  kernel  formatting  system 
(KFS)  to  format  the  results  a  buffer  at  a  time.  After  the 
last  buffer  is  processed  by  the  KFS  the  resulting  table  is 
displayed  and  control  then  returns  to  the  LIL. 

One  situation  worth  noting  is  the  processing  of  an  SQL 
nested-select  request.  An  n— level  SDL  nested-select  is 
mapped  to  n  corresponding  ABDL  retrieve  requests. 
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cofflputad  values;  however,  this  could  easily  have  been 
implemented  in  the  KFS  module.  We  have  chosen  not  to 
implement,  since  it  does  not  represent  a  feature  of  SQL  that 
is  inherently  relational. 

5.  Eliminating  Duplicates 

The  results  of  a  SELECT  query  may  contain 
duplicates.  The  eliminatirn  of  duplicates  is  normally  a 
high-cost  operation  and  often  unwarranted.  We  do  not 
pri^ide  such  an  option.  SQL  supports  the  elimination  of 
duplicates  through  the  use  of  the  UNIQUE  operator  in  the 
SELECT-clause.  Thus,  our  implementation  does,  not  support 
the  SQL  UNIQUE  operator. 

6.  Retri.eyal  USi-QQ  UNION 

The  work  of  Rollins  CRef.  3:  pp  82-831  has  described 
the  use  of  the  SQL  UNION  operator  in  a  query  comprised  of 
multiple  SELECT  constructs.  Each  SELECT  construct 
translated  to  an  equivalent  ABDL  RETRIEVE  construct,  and  all 
are  then  processed  by  MBDS  concurrently.  Rollins  has 
assumed  the  capability  to  eliminate  duplicates  in  the 
interface.  In  as  much  as  such  a  facility  is  not  provided  by 
our  implementation,  we  are  not  supporting  the  SQL  UNION 


operator . 


loop  concludes  with  some  steps  that  prepare  -for  the  next 
retrieve.  The  inner  loop  repeats  as  long  as  there  are  values 
left  in  the  current -results  file  and  the  procedure 
one_con junction  has  not  been  called.  The  outer  loop  then 
sets  up  for  the  next  ABDL  retrieve  and  concludes.  A  more 
detailed  example  of  hoM  the  procedures  h_conJunction , 
not_in_con junction,  and  one_con junction  work  will  be  covered 
in  the  following  two  sections.  * 

a.  The  N_con junction  Procedure 

The  procedure  n__con  junction  uses  the  ABDL 
request  template  and  the  values  from  the  previous  ABDL 
retrieve  stored  in  the  current-results  file  to  build  a 
fully— formed  ABDL  retrieve.  The  ABDL  request  template 
contains  a  portion  of  the  ABDL  request  which  we  have  labeled 
the  conjunction.  This  conjunction  portion  of  the  request 
template  is  bounded  by  the  first  set  of  outermost 
parenthesis  in  those  requests  handled  by  the  procedure 
n_con junct i on .  This  conjunction  contains  a  number  of 
predicates  that  are  "and'ed"  together.  A  BCedicate  is  a 
triple  consisting  of  an  attribute  name,  followed  by  a 
relational  operator  <i.e.,  >,  >=,  ...)  followed  by  an 
attribute  value.  Recall  that  in  an  earlier  discussion  we 
stated  that  the  request  template  contains  an  unspecified 
attribute-value.  In  our  current  terminology,  this  means 
that  a  predicate  in  the  conjunction  of  the  request  template 
has  an  unspecified  attribute  value.  To  mark  this  value 


within  the  request  template  character  string,  we  use  a 
series  o-f  asterisks,  where  the  number  o-f  asterisks 
corresponds  to  the  maximum  attribute-value  length.  The 
procedure  n_con junction  uses  the  conjunction  portion 
repeatedly  with  each  conjunction  having  a  different  value 
from  the  results  file  inserted  in  place  of  the  asterisks. 
The  conjunctions  are  then  "or'ed"  together  to  form  the 
fully— formed  ABDL  retrieve.  ♦ 

^  We  have  chosen  not  tg  allow  an  unlimited 
number  of  conjunctions  to  be  joined  together  into  one  ABDL 
request.  Rather  we  have  created  an  upper  limit  on  the 
maximum  number  of  conjunctions  that  may  be  joined  together 
into  a  single  ABDL  retrieve.  We  call  this  constant 
NUM_CONJ.  Thus,  assuming  we  have  NUM_CONJ  set  to  ten, 
only  ten  conjunctions  can  be  linked  together  in  one  ABDL 
retrieve.  This  means  only  ten  values  from  the  current- 
results  file  can  be  loaded  into  the  retrieve,  one  per 
conjunction.  If  there  are  more  than  ten  results  in  the 
current-results  file,  then  more  than  one  ABDL  retrieve 
must  be  built-  This  situation  necessitates  the  inner 
loop  discussed  in  the  procedure  sel ect_requests_handl er . 

We  now  look  at  an  example,  to  fully  understand 
the  operation  of  the  procedure  n_con junction.  We  will  build 
the  outer  ABDL  retrieve  for  the  nested  select  presented 
presented  in  Chapter  IV.  The  SOL  nested  select  is  as 


foil ows: 


SELECT  name,  age 
FROM  student 
WHERE  name  IN 

(  SELECT  name 

FROM  faculty  ) 

This  query  would  -find  the  name  and  age  of  all  students  who 
are  also  a  member  of  the  faculty.  The  KMS  maps  the  SQL 
nested— select  to  the  following  two  ABDL  retrieves. 

% 

*'  C  RETRIEVE  (TEMPLATE  =•  FACULTY)  (NAME)  3 

C  RETRIEVE  ( (TEMPLATE  =  STUDENT)  and 

(NAME  =  ***********))  (NAME,  AGE)  3 

The  first  ABDL  retrieve  which  corresponds  to  the  innermost 
SQL  request  is  e}<ecuted  by  the  procedure  sql_execute.  The 
results  of  this  retrieve  will  be  names  of  personnel  on  the 
faculty  are  stored  in  the  current-results  file.  We  assume 
that  there  are  three  names  returned  and  that  they  are 
Demur ji an.  Mack  and  Kloepping. 

The  procedure  n_con juncti on  marks  several 
locations  in  the  request  template  the  first  time  it  is 
called  for  a  particular  SQL  request.  The  procedure  stores 
the  location  of  the  beginning  and  the  end  of  the  conjunction 
and  the  location  of  the  first  and  last  asterisk  which 
delineates  the  unspecified  attribute— value.  In  the  previous 
example  the  conjunction  is  as  follows: 


( (TEMPLATE  ■  STUDENT)  and  (NAME  »  ***********) ) 

This  conjunction  is  to  be  used  three  times  to  construct  the 
fully— formed  ABDL  retrieve.  The  ABDL  retrieve  built  by  the 
procedure  n_con junction  is  shown  in  Figure  19. 

If  there  had  been  more  than  NUM_CONJ  names  in 

the  current-results  file,  then  more  than  one  fully-formed 

% 

ABDL  retrieve  would  have  to  be  generated  for  the 

corresponding  SQL  select.  The  first  NUM_CONJ  names  would 

have  to  be  inserted  into  predicates  that  are  “or'ed" 

together.  Another  ’ABDL  retrieve  would  then  be  built  using 

the  next  NUM_CaNJ  names  from  the  current-results  file.  ABDL 

retrieves  would  continue  to  be  built  until  all  names  in  the 

current-results  file  have  been  exhausted. 

b.  The  Procedures  Not_in_con junction  and 

Dne_con junction 

The  procedure  nat^in_con junction  operates  in  a 
similar  fashion  to  the  procedure  n_con junction.  The  major 
difference  is  that  the  conjunction  portion  of  the  request 

C  RETRIEVE  (((TEMPLATE  =  STUDENT)  and  (NAME  =  DEMUR J I AN))  or 

((TEMPLATE  =  STUDENT)  and  (NAME  =  MACK))  or 

((TEMPLATE  =  STUDENT)  and  (NAME  =  KLOEPPINB) ) ) 

(NAME,  AGE)  3 

Figure  19,  The  ABDL  Retrieve  Generated  by  the 
Procedure  N  conjunction. 


tsfflplate  is  smaller  and  the  conjunctions  arei  "and'6?d" 
together  rather  than  “or'ed”  together.  Suppose  that  we 
replace  the  IN  operator  in  the  previous  SQL  nested-select 
query  with  the  NOT  IN  operator.  The  resulting  SQL  query 
would  find  the  name  and  ages  o-f  all  students  who  are  not 
members  of  the  faculty.  The  first  ABOL  retrieve  would  be 
identical  to  the  first  ABDL  retrieve  in  the  last  example. 
The  second  ABDL  retrieve  would  now  b«  as  follows: 

a* 

C  RETRIEVE  ( (TEMPLATE  =  STUDENT)  and 

(NAME  ♦♦♦•»*■*♦**•**)  (NAME,  A6E)  3 

The  conjunction  portion  for  the  procedure  nDt_in_con junction 
would  be  as  follows: 

(  (TEMPLATE  *  STUDENT)  and  (NAME  '^=  *♦•»*■»**•»**•*)  ) 

The  procedure  not_in_con junction  inserts  the  names  from  the 
current-results  file  into  this  conjunction  and  "ands"  the 
conjunctions  together.  The  fully— formed  ABDL  retrieve  is 
shown  in  Figure  20. 


C  RETRIEVE  ((TEMPLATE  »  STUDENT)  and  (NAME  DEMURJIAN) 
and  (NAME  MACK)  and  (NAME  KLOEPPING)  ) 

(NAME,  AGE)  I 

Figure  20.  The  ABDL  Retrieve  Generated  by  the 
Procedure  Not_in_con junction. 

If  there  are  more  than  NUM_CGNJ  names  in  the  current-results 
file,  then,  as  before,  additional  ABDL  retrieves  would  be 
generated.  The  multiple  ABDL  retrieves  to  be  generated  are 
handled  identically  as  they  atre  in  the  -procedure 
n^cbn junction.  o 

The  procedure  one_con junction  manages  a  simpler 
situation.  For  the  procedure  one_conjunction-  we  are  also 
sent  an  ABDL  request  template  by  the  KMS.  In  these  type 
situations  all  that  must  be  done  is  to  replace  the  asterisks 
with  the  minimum  or  maximum  value  that  has  been  passed  into 
the  procedure  as  a  parameter.  Thus,  the  procedure 
ane_con junction  simply  removes  the  asterisks  and  inserts  the 
passed  in  value  in  its  place.  It  is  only  necessary  for  this 
single  ABDL  retrieve  to  be  generated  once.  For  example, 
suppose  we  are  processing  the  following  SQL  nested-select. 

SELECT  name,  age 
FROM  student 
WHERE  age  <ALL 

(  SELECT  age 
FROM  faculty  ) 


This  SQL  query  will  retrieve  the  names  and  ages  of  all 
students  that  have  an  age  less  than  all  the  faculty  ages. 


In  othar  words,  this  request  -finds  the  names  and  ages  o-f  all 

students  who  have  an  age  less  than  that  o-f  the  youngest 

« 

faculty  member.  The  KMS  maps  the  SQL  nested-select  to  the 
fallowing  two  ABOL  retrieves. 

C  RETRIEVE  (TEMPLATE  »  FACULTY)  (ASE)  3 

C  RETRIEVE  ( (TEMPLATE  »  STUDENT)  and 

(AGE  <a  ***))  (NAME,  AGE)  3 

« 

a 

Assume  the  first  retrieve  results  in  the  ages  of  54,  43,  37 

and  39  being  returned.  Since  the  SQL  operator  is  <ALL,  the 
minimum  age  i's  passed  to  the  procedure  one_con junction.  The 
fully-formed  ABOL  retrieve  that  the  procedure 
ane_con junction  generates  is  shown  in  Figure  21. 

C  RETRIEVE  (TEMPLATE  =»  FACULTY)  (AGE)  3 

C  RETRIEVE  ( (TEMPLATE  *  STUDENT)  and 

(AGE  <=  ***))  (NAME,  AGE)  3 

Figure  21.  The  ABDL  Retrieve  Generated  by  the 
Procedure  One  conjunction. 


VI.  IHg  KERNEL  FORMATTING  SYglEfl  <KF§) 


The  KF5  is  the  -fourth  module  in  the  SQL  language 
inter-face  and  is  called  from  the  kernel  controller  (KC) 
Mhen  the  KC  has  obtained  the  final  results  from  MBDS. 
The  results  are  passed  to  the  KFS  in  one  or  more  character 
buffers,  called  response  buffers-  If^ there  is  more  -than  one 
response  buffer,  the  KC  calls  the  KFS  again  for  each 
buffer.  The  KFS  manipulates  the  contents  of  these 
buffer(s)  to  create  an  image  of  an  SQL  results  table.  This 
table  is  formated  in  a  file  on  each  call  to  the  KFS. 
Hence,  this  allows  the  user  to  v- aw  the  results  of  his 
queries  as  if  he  is  working  with  an  SQL-type  database 
system.  The  following  example  illustrates  this  process: 

1.  The  user  issues  a  query: 

SELECT  NAME, AGE 
FROM  EMPLOYEE 
WHERE  AGE  <  30 

2.  The  query  is  processed  by  all  modules  of  the 
interface.  Eventually,  the  KC  receives  the  final  re- 
sul ts. 

3.  The  KC  calls  the  KFS  for  each  response  buffer. 

4.  The  KFS  uses  the  response  buffer  to  create  the  output 
table.  For  illustrative  purposes,  suppose  that  the 
response  buffer  contains  the  following  data: 

NAME  JOHN  AGE  29  NAME  STEVE  AGE  26 

5.  The  KFS  displays  the  appropriate  SQL  output  table: 


EMPLOYEE 


8 


8NAME 

8  AGE  8 

I  JOHN 

8  29 

8  STEVE 

8  26  8 

-  — - - — - * 

T  '  ■ 

It  is  important  for  the 

reader  to  note  that  the  table 

actually  consists  o-f  two  parts.  The  first  part  is  the 
table  heading  and  column  headings.  ^ In  the  example  above 
this  is  the  attribute  called  NAME  followed  by  the 
attribute  AGE.  These  are  column  headings.  The  table 
heading  consists  of  the  name  of  the  relation,  EMPLOYEE.  The 
second  part  is  instances  of  these  attribute  names  or 
results,  i.e. ,  attribute  values.  In  our  example,  JOHN  and 
STEVE  are  results  pertaining  to  the  attribute  NAME;  while 
29  and  26  are  the  results  pertaining  to  the  attribute  AGE. 

A.  THE  KFS  PROCESS 

In  this  section  we  discuss  the  processes  that  the  KFS 
uses  to  create  an  SQL  output  table.  We  present  these 
processes  in  the  same  sequence  as  they  are  performed  by 
the  KFS.  We  begin  this  discussion,  however,  with  an 
overview  of  those  data  structures  unique  to  the  KFS.  This 
overview  can  facilitate  our  understanding  of  the  C  code  that 
constitutes  this  module. 


1 


•  Qvervi  ew  o-f  the  KF5  Data  Structures 

The  KFS  utilizes,  -for  the  most  part-,  just  three  o-f 
the  structures  de-fined  in  the  language  interface.  The  -first 
of  these,  shown  in  Figure  22,  is  a  record  that  contains 

information  needed  by  the  KFS  to  process  the  results. 

The  first  field  in  this  record,  response,  contains  the 
result  from  MBDS  which  is  loaded  by  the  KC  just  prior  to 
calling  th^  KFS.  The  second  fielfl,  curr_pos,  ^ells  the 

KFS  where  it  is  in  the  response  buffet?.  This  helps  the  KFS 

maintain  a  correct  orientation  in  the  response  buffer.  The 
next  field,  res  len,  indicates  the  length  of  the 
response  buffer.  This  value  is  mostly  used  as  a 
halting  condition.  For  instance,  the  KFS  continues  to 
pull  characters  out  of  the  buffer  while  some  index  is  less 
than  or  equal  to  the  res_len.  The  next  field,  form^data,  is 
a  record  and  contains  information  about  the  output  table 
heading.  This  record  will  be  discussed  in  the  following 

struct  kfs  rel  info 


char 

•WTBsponse; 

int 

curr_pos; 

int 

res_len; 

struct 

tabl e_header _i nf  o 

f orm_data; 

struct 

f ile_info 

o_f ile; 

int 

status; 

struct 

rattr_nade 

■»f  irst_rel 

struct 

rattr_node 

■»sec_rel ; 

Figure  22.  The  kfs_rel_info  Data  Structure. 


The 


paragraph.  The  -fifth  field,  a_file,  is  also  a  record, 
o.file  record  contains  the  file  name  and  the  file 

identifier  of  the  file  that  the  KF5  is  building  the 

\ 

output  table  in.  This  is  needed  by  the  C  language  to  open 
the  output  file  for  read,  write,  or  append  access.  The 
next  field,  status,  acts  as  a  flag.  If  this  is  the  first 
time  the  KFS  is  entered  for  a  particular  set  of  response 
buffers  and,  therefore,  a  parti cul Sir  user,  then  this  field 
contains  a  value  of  FIRST I ME.  This  tells  the  KFS  that  it 
needs  to  initialize  values  and  set  various  structures  for 
subsequent  processing.  The  status  is  changed  after  this 
is  completed  so  that  this  initialization  is  not  to  be 
repeated  for  subsequent  calls  to  the  KFS  for  the  same  set 
of  responses.  The  seventh  field,  first_rel ,  is  a  pointer 
to  a  list  of  attributes  for  the  relation  being  currently 
processed.  The  data  pertaining  to  this  list  can  be 

considered  the  schema  of  the  current  relation.  The 
specific  data  that  is  needed  from  the  schema  is  the 
maximum  size  (in  terms  of  the  maximum  attribute  length) 
that  the  attribute  named  in  this  structure  can  possibly 
take  on.  This  information  is  needed  so  that  the  correct 
column  width  for  each  attribute  can  be  built  into  the  output 


table.  The  final 

field  is  used 

for 

the  same 

reasons 

discussed  above, 

but  is  needed 

to 

i mpl ement 

the  JOIN 

command . 
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Tha  second  structure  the  KFS  uses  extensively  is 
also  a  record  and  is  called  table_header_in-fa  and  is 
depicted  in  Figure  23.  The  purpose  o+  this  record  is  to 
provide  in-formation  about  the  heading  o-F  the  output  table. 
The  first  field,  table_Midth,  is  an  integer  value 
containing  the  width  of  the  output  table.  This 
information  tells  us  whether  or  not  the  tabid  can  fit 
within  one  horizontal  screen  width.  This  serves  as  the 
basis  for  some  of  our  logic  in  the  KFS  and  is  discussed  in 
detail  in  the  next  section.  The  next  field,  first_ent, 
points  to  another  record  that  contains  information  about 
the  first  attribute  name  in  the  heading  of  the  output 
table.  The  last  field  is  the  same  as  the  previous  one 
except  that  it  points  tb  the  the  current  table_entry_inf o 
record  that  the  KFS  is  now  working  with. 

The  third  data  structure,  like  the  previous  two, 
is  also  a  record.  This  record  maintains  all  of  the 
information  needed  to  correctly  position  attribute  names 
in  the  heading  of  the  output  table.  It  also  contains 

struct  tabl e_header_i nf o 

r 

c 

int  table_width; 

struct  tabl e_entry_inf o  *first_ent; 

struct  tabl e_entry_i nf o  ♦curr_Bnt; 

J 

Figure  23.  The  tabl e_header_inf o  Data  Structure. 


tha  in-formation  needed  to  correctly  position  the  results 
under  the  appropriate  headings.  The  first  field,  shown 
in  Figure  24,  is  a  character  array  containing  the  name  of 

an  attribute  that  is  used  as  part  of  the  output  table 

heading.  The  second  field  is  an  integer  value  containing 

the  length  of  the  stored  attribute  name.  This  value  is 
compared  with  the  next  field  to  determine  the  actual 
width  of  the  column  for  thi&  particular  attribute. 
Th4'  next  field,  val_len,  contains  /an  integer  value  that 
is  the  maximum  size  a  result  of  this  attribute  type  can 
possibly  take  on.  The  fourth-  field,  col  len,  holds  the 
maximum  of  the  two  previous  fields  and  is  the  actual 
width  of  a  column  for  a  particular  attribute  in  the  output 
table.  The  last  field,  next,  is  Just  a  pointer  to  the 

next  record  of  this  type.  Using  this  field  the  KFS  can 
move  from  one  record  to  . another  record  and  create  the 
correct  heading  until  it  hits  a  NULL  record. 

struct  tabl e_entry_i nf o 

C 

char 
int 
int 
int 

struct  tabl e_entry_inf o 
Figure  24.  The  tabl e_entry_inf o  Data  Structure. 


attrCANlength  13 
name_l en ; 
val_len; 
col_len; 

♦next; 


in-formation  is  used  by  the  KFS  to  create  the  header  part  of 
the  output  table. 

This  routine  begins  by  reading  the  first 
attribute  from  the  response  buffer.  The  string  length 
of  this  attribute  is  determined  next;  folloMed  by  a 
trace  through  the  list  of  attributes  in  the  schema  of 
the  current  relation.  The  trace  is  completed  when  this 
attribute  is  found  in  the  schema.  At^this  point,  the  maximum 
si2e  that  a  value  of  this  attribute  type  may  take  on  can  be 
determined.  This  information  is  stored  in  val_len.  The 
maximum  of  val_len  and  the  string  length  of  the  attribute 
is  then  calculated  and  placed  in  col_len.  This  value 
represents  the  actual  column  width  this  attribute  will 
have  in  the  output  table.  The  unwary  reader  may  miss  the 
importance  of  this  step.  It  is  easy  to  assume  that  the 
only  value  needed  is  val_len.  However, .  let’s  assume 
there  is  an  attribute  called  ZIP_CODE.  The  maximum  number 
of  characters  this  attribute  may  have  is  five  digits.  If 
we  do  not  consider  the  string  length  of  this  attribute 
name,  then  the  column  size  would  be  just  five  characters 
wide  and  ZIP_CODE  would  appear  as  ZIP_C  in  the  heading. 

This  process  of  reading  the  next  attribute  is 
iterated  until  either  it  has  cycled  through  a  series  of 
unique  attribute  names  or  it  has  processed  all  the 
attributes  in  the  response  buffer. 
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in-formation  is  used  by  the  KFS  to  create  the  header  part  o-f 
the  output  table. 

This  routine  begins  by  reading  the  first 
attribute  from  the  response  buffer.  The  string  length 
of  this  attribute  is  determined  next;  followed  by  a 
trace  through  the  list  of  attributes  in  the  schema  of 
the  current  relation.  The  trace  is  completed  when  this 
attribute  is 'found  in  the  schema.  At«this  point,  the  maximum 
si^e  that  a  value  of  this  attribute  type  may  take  on  can  be 
determined.  This  information  is  stored  in  val_len.  The 
maximum  of  val_len  and  the  string  length  of  the  attribute 
is  then  calculated  and  placed  in  col_len.  This  value 
represents  the  actual  column  width  this  attribute  will 
have  in  the  output  table.  The  unwary  reader  may  miss  the 
importance  of  this  step.  It  is  easy  to  assume  that  the 
only  value  needed  is  val_len.  However,,  let's  assume 
there  is  an  attribute  called  ZIP_CODE.  The  maximum  number 
of  characters  this  attribute  may  have  is  five  digits.  If 
we  do  not  consider  the  string  length  of  this  attribute 
name,  then  the  column  size  would  be  Just  five  characters 
wide  and  ZIP_CODE  would  appear  as  ZIP_C  in  the  heading. 

This  process  of  reading  the  next  attribute  is 
iterated  until  either  it  has  cycled  through  a  series  of 
unique  attribute  names  or  it  has  processed  all 

attributes  in  the  response  buffer. 


the 


c.  Crsating  the  Table  in  the  Output  File 

This  part  o-f  the  KFS  can  be  considered  the 

workhorse  of  the  module.  The  previous  two  processes 

are  instrumental  in  manipulating  data  structures  and 

setting  variable  values  so  that  this  process  may  -ful-fill  the 

intended  mission  o-F  the  KFS.  There-fore,  we  discuss  some 

o-F  the  issues  we  have  struggled  with  while  designing  this 

part  O-F  the  KFS.  The  two  most  important  issues  are^ 

r.  How  should  the  table  appear  to  the  user? 

2.  How  should  the  table  be  stored  internally,  i.e. , 
should  it  be  in  a  -File,  a  character  array,  or  dis¬ 
played  immediately  to  the  user? 

Our  problem  has  been  that  we  have  had  no 

concrete  examples  o-F  what  an  SQL  table  should  look  like. 
Should  the  headings  be  centered  within  the  columns, 

with  the  results  centered  under  these  headings?  We 
didn't  know.  We  Finally  decided  upon  a  convention  that 
would  Facilitate  programming.  Hence,  we  leFt-JustiFied  both 
the  headings  and  the  results  with  blanks  added  at  the  end  oF 
each  to  insure  proper  spacing  within  the  columns.  As  it 

turned  out,  this  is  also  the  way  Date  CReF.  17;  pp.  117-1423 

presents  his  examples. 

The  second  issue  has  posed  a  problem.  Our 
initial  design  has  called  For  building  the  table  in  a 
character  array.  The  only  other  alternative  considered  at 
this  time  has  been  to  immediately  put  the  table  on  the 
screen  as  results  are  being  passed  to  the  KFS.  This  idea 
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difficulties  of  trying  to  build  a  table  on  the  fly>  In  a 
sifliilar  fashion,  >  the  idea  of  building  the  table  in  a 
character  array  is  also  dismissed.  There  is  no  way  for 
us  to  predetermine  the  size  of  this  array.  We  have 
thought  that  it  is  uneconomical  to  allocate  a  huge  array 
to  cover  all  possible  table  sizes.  There  is  also  the 
problem  of  moving  around  in  the  lirray.  This  "  indexing 
problem  created  a  preponderance  of  C  code. 

□ur  only  other  alternative  is  to  build  the  table 
in  a  file.  This  method  has  proved  very  easy  to  do.  The 
operating  system  maintains  position  within  the  file,  so, 
there  is  no  indexing  problem.  In  addition,  there  is  more 
economical  use  of  the  computer's  resources,  since  the  file 
is  only  as  big  , as  necessary.  Hence,  we  have  opted  to  build 
the  table  in  a  file. 

With  these  issues  resolved,  the 

implementation  of  this  process  has  been  straightf orward. 
First,  the  headings  are  built  in  the  output  file.  This 
is  done  only  the  first  time  the  KFS  is  called.  Next,  the 
attribute  values  are  pulled  from  the  response  buffer  and 
placed  left- justified  under  the  corresponding 

attribute.  Then,  the  process  is  iterated  until  the 
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rasponse  buffer  is  exhausted.  Subsequent  calls  to  the  KFS 
for  the  same  set  of  queries  cause  results  to  be  appended 
to  the  table  in  the  file. 

d.  Displaying  the  Table 

The  KFS  displays  the  SQL  table  to  the  user  when 
all  response  buffers  have  been  processed.  This  occurs 
when  a  special  signal  is  detected  in  the  last  buffer  in 
conjunction  with  the  setting  of* a  status  signifying  the 
last  sub_request  of  a  nested  select.  :  An  initial  problem  we 
have  had  with  this  process  has  been  how  to  display  a 
table  more  than  twenty-four  lines  long.  A  unique 
procedure,  patterned  after  the  'more'  facility  in  UNIX 
CRef.  18],  is  developed.  This  function,  when  first 
called,  displays  the  first  twenty-two  lines  of  the  SQL 
table  and  then  prompts  the  user.  The  user  can  choose  from 
a  number  of  options.  For  instance,  the  user  can  have 
another  screen-full  of  results  displayed,  or  the  user  can 
display  some  number  of  lines  less  than  twenty-two,  or  the 
user  can  even  terminate  the  current  menu  of  the  language 
interface.  Our  intent  is  to  make  viewing  the  results  as 
convenient  as  possible  to  the  user. 

e.  Cleaning  Up 

Before  leaving  the  KFS,  the  data  structures 
used  to  create  the  SQL  table  are  freed.  This  ensures  that 
the  resources  are  available  to  process  other  queries. 
Additionally,  the  status  field  is  updated  to  FIRSTIME.  This 


placM  the  KFS  in  the  correct  state  to  process  subsequent 
queries  correctly. 

B.  A  LIMITATION  OF  THE  KFS 

Although  we  have  tried  to  make  the  KFS  as  general 

as  possible  with  regard  tO  creating  and  displaying  SQL 

tables,  there  is  one  facility  we  have  deliberately 

neglected  to  incorporate.  This  is  the  ability  to  display 

I 

tables  with  widths  greater  than  eighty  columns.  Since 
our  intent  is  to  only  show  that  the  interface  could 
indeed  be  developed,  we  have  decided  that  the  programming 
effort  required -to  provide  this  facility  is  too  costly  for 
the  benefits  derived.  However,  this  is  not  to  imply  that 
this  facility  is  not  useful  or  needed.  As  a  matter  of 
fact,  we  have  intentionally  designed  the  KFS  for  the  easy 
insertion  of  this  code  when  it  is  developed. 


VII.  CONCLUSION 


In  this  thesis,  we  have  presented  the  specification 
and  ifflplefflentation  of  a  SQL  language  interface.  This  is 
one  of  four  language  interfaces  that  the  multi -lingual 
database  system  will  support.  In  other  words,  the  multi¬ 
lingual  database  system  will  be  able«to  execute  transactions 
wri'-tten  in  four  well-known  and  important  data  languages, 
namely,  SQL,  OL/I,  Oaplex,  and  CODASYL.  SQL  is  of  course 
the  well-known  relational  data  language  provided  by,  for 
example,  IBM  SQL/Data  System.  In  our  case,  we  support  SQL 
transactions  with  our  language  interface  by  way  of  LIL,  KC, 
KMS,  and  KFS  in  place  of  SQL/Data  System.  A  related  thesis 
by  Benson  and  Wentz  CRef.  193  ,  examines  the  specification 
and  implementation  of  the  DL/I  language  interface.  Two 
other  theses  on  CODASYL  and  Daplex  respectively  are  under 
way.  This  work  is  part  of  ongoing  research  being 
conducted  at  the  Laboratory  of  Database  Systems  Research, 
Naval  Postgraduate  School,  Monterey,  California. 

The  need  to  provide  an  alternative  to  the  development 
of  separate  stand-alone  database  systems  for  specific  data 
language  models  has  been  the  motivation  for  this  research. 
In  this  regard,  we  have  first  demonstrated  the  feasibility 
of  a  mul ti -1 i ngual  database  system  (MLDS)  by  showing  how  a 
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softwar*  SQL  language  interface  can  be  constructed. 
Specific  contributions  of  this  thesis  include  the 
development  of  useful  algorithms  and  the  implementation 
of  SQL  operations  such  as:  nested  retrieval.  Join 
operations,  retrieval  of  grouped  attributes,  and  updating 
multiple  fields.  In  addition,  we  have  developed  a  LIL  that 
is  virtually  reusable.  With  minor  modifications  the  LIL  can 
be  used  with  the  other  language  intelkfaces.  As  a  matter  of 
fact,  it  has  been  recently  modified  for  the  DL/I  language 
interface.  Our  design  of  the  generic  data  structures  is 
also  noteworthy.  Because  of  our  extensive  utilization  of 
unions  (i.e.,  variant  records),  the  other  language 
interfaces  can  use  our  generic  data  structures.  We  have 
extended  the  work  of  Macy  CRef.  22  and  Rollins  CRef.  31  by 
specifying  and  implementing  the  algorithms  for  the  language 
interface.  In  addition,  we  have  also  provided  a  general 
organizational  description  of  a  MLDS. 

A  major  goal  has  been  to  design  a  SQL-to-MBDS  interface 
without  requiring  any  change  be  made  to  MBDS  or  ABDL.  Our 
implementation  may  be  completely  resident  on  a  host 
computer  or  the  controller.  All  SQL  transactions  are 
performed  in  the  SQL  interface.  MBDS  continues  to 
receive  and  process  transactions  written  in  the  unaltered 
syntax  of  ABDL.  In  addition,  our  implementation  has  not 
required  any  change  to  the  syntax  of  SQL.  The  interface  is 
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completely  transparent  to  the  SQL  user  as  well  as  to  the 
MBOL. 

In  retrospect,  our  level-by— level ,  top-down 
approach  to  the  design  of  the  interface  has  been  a  good 
choice.  This  implementation  methodology  has  been  the  most 
familiar  to  us  and  proved  to  be  relatively  efficient  in 
time.  In  addition,  this  approach  permits  follow-on 
programmers  to  easily  maintain  and* modify  (when  necessary) 
the  code.  Subsequently,  they  will  know  exactly  where  we 
have  stopped  and  where  they  should  begin  because  we  have 
included  many^  of  the  lower — level  stubs.  Hence,  it  is  an 
easy  task  of  filling  in  these  stubs  with  code. 

Me  have  shown  that  a  SQL  interface  can  be  implemented 
as  part  of  a  MLDS.  We  have  provided  a  software 
structure  to  facilitate  this  interface,  and  we  have 
developed  the  actual  code  for  implementation.  The  next 
step  is  to  implement  the  other  interfaces.  When  these 
are  complete,  the  system  needs  to  be  tested  as  a  whole  to 
determine  how  efficient,  effective,  and  responsive  it  is 
to  users'  needs.  The  results  may  be  the  impetus  for  a  new 
direction  in  database  system  research  and  development. 
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APPENDIX  A  -  SCHEMATIC  OF  THE  DATA  STRUCIURES 

The  purpose  o-f  this  appendix  is  to  present  a  pictorial 
o-f  data  structures  used  in  the  SQL  language  interface. 
Since  the  code  used  for  the  thesis  was  the  C  programming 
language,  the  diagram  makes  use  of  its  constructs  Just 
as  the  code  does.  Groups  of  related  items  are  known  as 
structures  in  C,  and  it  is  easy  to  see  from  the  diagram 
that  the  structures  break  down  into^more  detailed,  workable 
sti^uctures.  There  are  two  major  parts  of  this  appendix.  In 
Figure  25  we  present  the  relational  database  schema  data 
structures  that  were  discussed  in  Chapter  2.  In  Figure 
26  we  present  the  user  data  structures. 

In  the  diagrams  an  arrow  indicates  that  the  field 
is  a  pointer  to  a  structure.  Each  of  the  fields  of  such 
a  structure  is  preceded  by  a  small  arrow  to  indicate  that 
indeed  a  pointer  from  another  structure  is  referencing 
the  field.  An  example  of  this  is  the  field  si_ddl_files 
o^  the  SOL_INFO  structure  in  Figure  26  on  page  113.  The 
field  si_ddl_files  paints  to  a  structure  of  type  DDL_INFO. 
This  is  especially  useful  when  writing  or  tracing  long  paths 
through  the  user  data  structure. 

On  the  other  hand,  bracket  lines  are  used  to  indicate 
when  a  field  of  a  structure  is  also  a  structure.  The 
bracket  lines  are  drawn  from  the  “parent"  field  to  the 
"child"  structure.  A  period  is  placed  in  front  of  the 
bracketed  structure's  fields  to  indicate  this  fact.  An 
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example  o-f  this  is  the  si_sql_tran  -field  o-f  the  S(3L_INF0 
structure  in  Figure  26  on  page  112-  The  field  si_sql_tran 
is  a  structure  of  type  TRAN_INFO.  The  bracket  lines  and  the 
periods  indicate  this. 

We  note  that  the  diagram  has  a  few  instances  of  UNIONS. 
A  union  is  a  construct  that  allows  the  user  to  connect 
different  structure  types,  specified  by  the  union 
structure,  to  a  common  structure,'  i.e.,  unions"  are  also 
ref’Wed  to  as  variant  records.  Since  the  multi -1  ingual 
database  system  is  to  support  the  mapping  of  multiple 
.languages,  many  portions  of  the  user  structure  will  be  the 
same  for  any  language  used.  However,  the  union  construct 
allows  for  the  parts  that  must  change  between  language 
interfaces  so  that  the  common  data  structures  can  be  adapted 
to  be  useful  to  all  of  the  language  interfaces. 
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APPENDIX  B  -  THE  LIL  PROGR.\M  SPECIFICATIONS 


module  SQL-INTERFACE 

db-list  :  list;  /*  list  of  existing  relational  schemas  */ 
head-db-list-ptr;  ptr;  j*  ptr  to  head  of  the  relational  schema  list  * / 
current-ptr:  ptr;  /*  ptr  to  the  current  db  schema  in  the  list  */ 
follow-ptr:  ptr;  /*  ptr  to  the  previous  db  schema  in  the  list  */ 
db>id  :  string;  /*  string  that  identifies  current  db  in  use  * / 

proc  LANGUAGE-INTERFACE-LAYERO;  ^ 

/*  This  proc  allows  the  user  to  interface  with  the  system.  */ 

-y*  Input  and  output:  user  SQL  requests  ^  */ 

stop  :  int;  /*  boolean  flag  */ 

answer:  char;  /*  user  answers  to  terminal  prompts  */ 

perform  SQL-INI'f();~  ' 
stop  =  ’false’; 
while  (not  stop)  do 

/*  allow  user  choice  of  several  processing  operations  */ 

print  ("Enter  type  of  operation  desired”); 

print  (”  (1)  -  load  new  database”); 

print  ("  (p)  -  process  existing  database”); 

print  ("  (x)  -  return  to  the  to  operating  system"); 

read  (answer); 

case  (answer)  of 

’1’:  /*  user  desires  to  load  a  new  database  */ 
perform  LOAD-NEW(); 

’p’:  /*  user  desires  to  process  an  existing  database  */ 
perform  PROCESS-OLD(): 

’x’:  /*  user  desires  to  exit  to  the  operating  system  */ 

/*  database  list  must  be  saved  back  to  a  file  */ 
store-free-db-list(head-db-list,  db-list); 
stop  =  ’true’; 
exit(); 

default:  /*  user  did  not  select  a  valid  choice  from  the  menu  * 
print  ("Error  -  invalid  operation  selected"); 
print  ("Please  pick  again")’ 
end -case; 

/*  return  to  main  menu  *  / 
end-while; 

end-proc; 
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proc  SQL-INIT(); 
end-proc; 


proc  LOAD-NEWO; 

/*  This  proc  accomplishes  the  following:  */ 

/*  (1)  determines  if  the  new  database  name  already  exists.  */ 

/*  (2)  adds  a  new  header  node  to  the  list  of  schemas,  *  j 

/*  (3)  determines  the  user  input  mode  (file/ terminal),  */ 

/*  (4)  reads  the  user  input  and  forwards  it  to  the  parser,  and  * / 
I*  (5)  calls  the  routine  that  builds  the  template/descriptor  files  */ 

\ 

answer:  int;  /*  user  answer  to  terminal  prompts  */ 

'-more-input:  int;  /*  boolean  flag  */ 
proceed:  int;  /*  boolean  flag  */ 
stop  :  int;  /*  boolean  flag  */ 

db-list-ptr:  ptr;  /*  pointer  to  the  current  database  */ 
req-str:  str;  .  /*  single  create  in  SQL  form  */ 
ptr-abdl-list:  ptr;  /’*'ptr  to'a  list  of  ABDL  queries  (nil  for  this  proc)*/ 
tfid,  dfid:  ptr;  /*  pointers  to  the  template  and  descriptor  files  */ 


/*  prompt  user  for  name  of  new  database  */ 
print  ("Enter  name  of  database"); 
readstr  (db-id); 
db-list-ptr  =  head-db-list-ptr; 

stop  =  ’false’; 
while  (not  stop)  do 

/*  determine  if  new  database  name  already  exists  */ 
/*  by  traversing  list  of  relational  db  schemas  */ 
if  (db-list-ptr.db-id  =  existing  db)  then 
print  ("Error  -  db  name  already  exists"); 
print  ("Please  reenter  db  name"); 
readstr  (db-id); 
db-list-ptr  =  head-db-list-ptr; 
end-if; 
else 

if  (db-list-ptr  1  =  ’nil’)  then 
stop  =  ’true’; 
else 

/*  increment  to  next  database  */ 
db-list-ptr  =  db-list-ptr  -r  1; 

^  end-else; 


end-while; 


/  continue  •  user  input  a  valid  new*  database  name  / 

/*  add  new  header  node  to  the  list  of  schemas  and  fill-in  db  n^me  *  j 
/*  append  new  header  node  to  db-list  */  ~- 

create-new-db(db-id); 

/*  the  KMS  takes  the  SQL  creates  and  builds  a  new  list  of  relations  *  / 
/*  for  the  new  database.  After  all  of  the  creates  have  been  processed  */ 
/*  the  template  and  descriptor  files  are  constructed  by  traversing  */ 
/*  the  new  database  definition  (schema).  */ 

more-input  =  ’true’; 
while  (more-input)  do 

/*  determine  user’s  mode  of  input  */  « 

print  ("Enter  mode  of  input  desired"); 

pHnt  ("  (f)  •  read  in  a  group  of  creates  from  a  file".); 

print  ("  (t)  -  read  in  a  single  create  from  the  terminal"); 

print  ("  (x)  -  return  to  the  main  menu"); 

read  (answer); 

case  (answer)  of  * 

’f ;  j*  user  input  is  from  a  file  */ 

perform  READ-TRANSACTI0N-FILE(); 
perform  CREATES-TO-KMS(); 
perform  FREE-REQUESTS(); 
perform  BUILD-DDL-FILES(); 
perform  KERNEL-CONTROLLERO; 

’t’:  /*  user  input  is  from  the  terminal  */ 
perform  READ-TERMINAL(); 
perform  CREATES-TO-KMS(); 
perform  FREE-REQUESTS(); 
perform  BUILD-DDL-FILES(); 
perform  KERNEL-CONTROLLER(); 

’x’:  /*  exit  back  to  LIL  */ 
more-input  =  ’false’; 

default:  /*  user  did  not  select  a  valid  choice  from  the  menu  */ 
print  ("Error  -  invalid  input  mode  selected"); 
print  ("Please  pick  again"); 
end-case; 
end-while; 


end  proc; 
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proc  PROCESS-OLD(); 

/*  This  proc  accomplishes  the  following:  */ 

/*  (1)  determines  if  the  database  name  already  exists,  *  / 
/*  (2)  determines  the  user  input  mode  (file/terminal),  * / 
/*  (3)  reads  the  user  input  2md  forwards  it  to  the  parser  * / 


answer:  int; 
foimd:  int; 
more-input:  int: 
proceed:'  int; 
db-list-ptr:  ptr; 
req-str:  str; 


*  / 


/*  user  answer  to  terminal  prompts 
/*  boolean  flag  to  determine  if  db  name  is  found  *  / 
/*  boolean  flag  to  return  user  to  LIL  */ 

/*  boolean  flag  to  retiirn  user  to  mode  menu  *  / 

/*  pointer  to  the  current  database  */ 

/*  single  query  in  SQL  form  */ 
ptr-abdl-list:  ptr;  /  *  pointer  to  a  list  of  queries  in«^BOL  form  */ 
tfid,  dfid:  ptr;  /*  pointers  to  the  template  and  descriptor  files  */ 


/*  prompt  user  for  name  of  existing  database  */ 

print  ("Enter  name  of  database"); 

readstr  (db-id); 

db-list-ptr  =  head-db-list-ptr;' 

found  =  ’false’; 
while  (not  found)  do 

/*  determine  if  database  name  does  exist  */ 

/*  by  traversing  list  of  relational  schemas  */ 
if  (db-id  =  existing  db)  then 
found  =  ’true’; 
end-if; 
else 

db-list-ptr  =»  db-list-ptr  -t-  1; 

/*  error  condition  causes  end  of  list(’nir)  to  be  reached  */ 
if  (db-list-ptr  =  ’nil’)  then 
print  ("Error  -  db  name  does  not  exist"); 
print  ("Please  reenter  valid  db  name"); 
readstr  (db-id); 
db-list-ptr  =  head-db-list-ptr; 
end-if: 

end-else; 


end-while; 


/*  continue  •  user  input  a  valid  existing  database  name  * / 
I*  determine  user’s  mode  of  input  *  / 


more-input  —  ’true’; 
while  (more-input)  do 
print  ("Enter  mode  of  input  desired"); 
print  ("  (f)  -  read  in  a  group  of  queries  from  a  file"); 

print  ("  (t)  -  read  in  a  single  query  from  the  termined"); 

print  ("  (x)  -  return  to  the  previous  menu"); 

read  (answer); 

case  (answer)  of 

’f :  /*  user  infuit  is  from  a  file  */  \ 

perform  READ-TRANSACTION-PILE(); 
perform  QUERIES-TO-KMS(): 
perform  FREE-REQUESTS(); 

’t’:  /*  user  input  is  from  the  terminal  */ 
perform  READrTERMINAL(); 
perform  QUERIES-T0.KMS(); 
perform  FREE-REQUESTS(); 


’x’:  /*  user  wishes  to  return  to  LIL  menu  */ 
more-input  =  ’false’; 


default:  /*  user  did  not  select  a  valid  choice  from  the  menu  */ 
print  ("Error  -  invalid  input  mode  selected"); 
print  ("Please  pick  again"); 
end-case; 


end-while; 

end-proc; 


proc  READ-TRANSACTION-FILE(); 

/*  This  routiae  opens  a  create/query  file  and  reads  the  requests  */ 
/*  into  the  request  list.  If  open  file  fails,  loop  until  valid  * ! 

/*  file  entered  */ 

while  (not  open  file)  do 
print  ('’Filename  does  not  exist"); 
print  ("Please  reenter  a  valid  filename"); 
readstr  (  file); 
end-while; 

READ-FILE(); 

% 

% 

end-proc; 


proc  READ-FILE(); 

/*  This  routine  reads  transactions  from  either  a  file  or  the  */ 

/*  terminal  into  th?  user’s  request  list  structure  so  that  */ 

/*  each  request  may  be  sent  to  the  KERNEL-MAPPING-SYSTEM. 

end-proc; 


proc  READ-TERMINAL(); 

/•  This  routine  substitutes  the  STDIN  filenaune  for  the  read  */ 

/*  command  so  that  input  may  be  intercepted  from  the  terminal  */ 

end-proc; 


proc  CREATES-TO-KMS(); 

/*  This  routine  sends  the  request  list  of  creates  one  by  one  */ 

/*  to  the  KERNAL-MAPPING-SYSTEM  */ 

while  (more-creates)  do 
KERNAL-MAPPING-SYSTEMO; 
end-while; 


end-proc; 


proc  QUERIES-TO-KMS(); 

/*  This  routine  causes  the  queries  to  be  listed  to  the  screen.  * ! 
j*  The  selection  menu  is  then  displayed  allowing  any  of  the  */ 
/*  queries  to  be  executed.  */ 

perform  LIST.QUERIES(): 
proceed  ■=  ’true’; 
while  (proceed)  do 

print  ("Pick  the  number  or  letter  of  the  action  desired"); 
print  ("  (num)  -  execute  one  of  the  preceding  queries"); 
print  ("  (d)  -  redisplay  the  file  of  queries"); 

print  ("  (x)  -  return  to  the  previous  menu"); 

read  (answer);  ■.  ^ 

case  (Mswer)  of 

’num’  :  /*  execute  one  of  the  queries  */ 
traverse  query  list  to  correct  query; 
perform  KERNAL-MAPPING-SYSTEM(): 
perform  KERNEL-CONTROLLERO; 

’d’  :  /*  redisplay  queries  */ 

perform  LIST-QUERIES(); 

’x’  :  /•  exit  to  mode  menu  */ 

proceed  —  ’false’; 

default  :  /*  user  did  not  select  a  valid  choice  from  the  menu  “/ 
print  ("  Error  -  invalid  option  selected"); 
print  ("  Please  pick  again"); 
end-case; 

end-while; 

end-proc; 


end-module; 


APPENDIX  C  -  THE  KMS  PROGR.\M  SPECIFICATIONS 


module  KMS  () 
perform  parser() 
end-module  KMS 


proc  yypaxse  ()  , 

% 

•'J*  This  proc  accomplishes  the  following  ;  ,  */ 

/*  (l)  parses  the  SQL  input  requests  and  maps  thehi  to  appropriate  */ 
/*  abdl  requests,  using  LEX  and  YACC  to  build  proc  yyparse{).  */ 
/*  (2)  builds  the  relational  schema,  when  loading  a  new  database.  */ 

/*  (3)  checks  for  validity  of  relation  and  attribute  names  within  */. 

/*  the  given  db-  schema,  when  processing  requests  against  an  */ 

/*  existing  database.  */ 


%{ 


list:  tgt-list  /*  list  of  attribute  names  */ 

list;  templates  /*  relation  name(3)  */ 

list:  insert-list  /*  list  of  values  for  insertion  op  */ 

string;  temporary-str  /*  used  for  accumulation  of  query  conjuncts  */ 


string:  abdl-str 
string:  join-str 
boolean:  nested 
boolean;  creating 
boolean:  or-where 
boolean:  and-where 
boolean;  set-member 
boolean:  common- attr 
boolean;  rell 
boolean:  rel2 
boolean:  or-abdl-join 
boolean;  or-kms-join 
boolean:  delete-all 
int:  target-list-length 
int:  insert-list-length 
int:  no-templates 
int:  no-attributes 
int:  attr-len 
char:  attr-type 
char;  db[] 
char;  template[j 
char:  attributejj 


/*  used  for  accumulation  of  abdl  request  */ 

/*  used  for  accumulation  of  join  request  */ 

/*  signals  a  nested  SELECT  query  * / 

/*  signals  a  DbLoad  -  versus  a  DbQuery  */ 

/*  signals  an  OR  term  in  the  WHERE  clause  */ 

/*  signals  an  AND  term  in  the  WHERE  clause  */ 
/•  signals  set  membership  op,  vice  nested  SEL  */ 
/*  signals  COMMON  attr  predicate  of  JOIN  op  * 
/*  signals  curr  predicate  assoc'd  w/lst  join  rel  */ 

/*  signals'  curr  predicate  assoc’d  w/2nd  join  rel  */ 

/*  OR  in  1st  join  retrieve  request  */ 

/*  OR  in  2nd  join  retrieve  request  * / 
f*  signals  deletion  of  all  records  in  relation  < 


%  start  statement 

%  token  /*  LIST  ALL  TOKENS  FROM  "LEX",  and  their  TYPE,  HERE  */ 

%% 

statement:  query 

{ 

nested  =  FALSE 

free  all  tgt/insert  lists  and  temp-str  (malloc’d  vars) 
return 

} 

I  dml-statement 

{  ' 

cat  End-Of-Request  ("]")  to  end  of  abdl-str 

free  all  tgt/insert  lists  and  temp-str  (malloc’d"' vars) 

return 

} 

I  ddl-statement 

{  •- 
return 

} 


dml-statement:  insertion 
1  deletion 
;  update 


query:  query-expr 


query-expr:  query-block 

{ 

cat  End-Of-Request  ("j")  to  end  of  abdl-str 

} 
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p-i.  vy  'n  '•'1'^!'  '■T^n 


query-block:  seleci  'lause  FROM  from-Iist 

{ 

for  (ea  attribute  name  in  tgt-list) 
if  (!  join) 

if  NOT  valid-attribute(db,  template,  attribute,  attr-len) 
print  {’’Error  -  field  name  ’attribute-name'  does  not  exist") 
perform  yyerror{) 
return 
•nd-if 
end-if 
else 

a  join  exists  —  check  that  tgt-rel(s)  match  at  least 
one.from-list  relation  ^ 

if  (match  neither)  * 

print  ("Error  -  ’attr’  attr  not  in  from-list  relations") 
perform  yyerror() 
return 
end-if 
end-else 
end-for* 

cat  "("  to  abdl-str 
if  (join) 

cat  "("  to  join-str 
end-if 
if  (nested) 

fill  temporary-str  w/’*’s  marking  the  length  of  the  tgt  attr 
end-if 

} 

A 

{ 

cat  ")"  to  abdl-str 
if  (!  join) 

cat  "(’tgt-list’)"  to  abdl-str 
end-if 
else 

cat  "(’tgt-list’)"  to  abdl/join-str,  as  appropriate 
construct  the  rest  of  the  abdl  join  request 
(ie,  cat  COMMON-str  to  abdl-str;  cat  join-str  to  abdl-str) 
end-else 

} 

B 
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A;  empty 

{ 

cat  ’’FILE  =  ’relation-name’"  to  abdl-str 

} 

1  WHERE  booleem 
{ 

if  (!  join)  &&  (or-where) 
cat  ")"  to  abdl-str 
•  end-if 

else  if  (or-abdl-join) 
cal  ")"  to  abdl-str 
end-elseif 

elseif  (or-kms-join) 
cat  ")"  to  join-str 
'.end-elseif 

} 


B:  empty 

i  GROUP  BY  fierd-spec-list 
{ 

cat  "BY  ’attribute-name’"  to  abdl-str 

} 


select-clause;  SELECT 

{ 

if  (nested) 

allocate  another  set  of  tgt /insert  lists,  temporary- str, 
and  abdl  strings 
end-if 

copy  RETRIEVE  "  to  beginning  of  abdl-str 

} 

C 


C:  sel-expr-list 
MULTOP 
{ 

*  retrieval  of  "all"  attribute  values  desired  */ 
if  (MULTOP  value /= ’*’) 
print  ("Error  -  asterisk(*)  operator  expected") 
p)erform  yyerror() 
return 
end-if 


sel-expr-list:  sel-expr 

{ 

copy  first  attribute  name  to  tgt-list 

} 

j  sel-expr-list  COMMA  sel-expr 

copy  successive  attribute  name(s)  to  tgt-list 

} 


sel-expr:  expr 


insertion:  INSERT  INTO 

copy  ”[  INSERT  ("  to  beginning  of  abdl-str 

} 

receiver  COLON  insert-spec 

{  .... 

cat  ")”  to  abdl-str  • 

} 


receiver:  table-name 

cat  "<FILE,  ’relation-name’ >”  to  abdl-str 

} 

D 
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D:  empty 

{ 

/*  inserting  info  for  "all"  attribute  values  */ 
copy  all  attribute  names  from  schema  to  tgt-list 
if  (target-list-length  <  1) 
print  ("Error  -  rel  does  not  exist,  or  has  no  attr’s") 
perform  yyerror() 
return 
end- if 
} 

LPAR  field-name-list  RPAR 

{ 

for  (ea  attribute  name  in  tgt-list) 
if  NOT  valid-attribute(db,  template,  attribute,iattr-len) 
print  ("Error  -  field  name  ’attribute-name’  does  not  exist) 
perform  yyerror()  : 

return 
end-if 
end- for 

}  :  ::  : 

field-name-list:  field-name 

{ 

target-list-length-^-+- 

copy  first  attribute  name  to  tgt-list 

} 

field-name- list  COMMA  field-name 

{ 

target-list-length-^-*- 

copy  successive  attribute  name(s)  to  tgt-list 

} 

insert-spec:  literal 

{ 

if  (length  of  tgt-list  <>  length  of  insert-list) 
print  ("Error  -  not  enough  or  too  many  values  inserted") 
perform  yyerror() 
return 
end-if 

for  (ea  attribute  in  tgt-list  ea  value  in  insert-list) 
perform  type-checking  of  attrribute- value  pairs 
cat  ",< ’attribute-name’,  ’insert-yalue’>"  to  abdl-str 
end-for 


deletion:  DELETE  table-name 

{  • 

copy  "[  DELETE  (  "  to  abdl-str 
copy  ’table-name’  to  templates 

} 

E 

{ 

if  (delete-all) 

cat  "TEMPLATE  =  ’table-name’"  to  abdl-str 
end-if 

cat  ")"  to  abdl-str 

} 


E;  {inpty 

{ 

delete-all  =  TRUE 

} 

I  WHERE  boolean 

{  * 
if  (or-where) 
cat  ")"  to  abdl-str 
end-if 
} 


update:  UPDATE  table-name 

{ 

copy  "[  UPDATE  (  "  to  beginning  of  abdl-str 
copy  relation-name  to  templates 
} 

set-clause-list  F 

{ 

cat  ")  ’set-clause-list’"  to  abdl-str 

} 


F:  empty 

WHERE  boolean 

{ 

if  (or-where) 
cat  ")"  to  abdl-str 
end-if 
} 
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proc  load-tablesO 


/*  This  procedure  accomplishes  the  following;  */ 

/*  (1)  Calls  dbl-template()  which  is  a  procedure  */ 

/*  already  defined  in  the  Test  Interface.  It  loads  */ 

/*  the  template  file.  */ 

/*  (2)  Calls  db]-dir-tbls()  which  is  another  procedure  */ 
/*  already  defined  in  the  Test  Interface.  It  loads  */ 

/*  the  descriptor  file.  */ 

begin  proc 

do  initialization;  /*  Initialize  pointer  */ 
perform  dbl-template(<Sdtemplate,  ptr->ddli-temp.fi-fid); 
perform  dbl-dir-tbls(ptr- >ddli-desc.fi-fid); 
end  proc 


proc  rest-requests-handler() 

!*  This  procedure  handles  common  retrieve  requests,  insert  * / 
'*  requests,  delete  requests  and  update  requests  by  calling  */ 
i*  sql-execuie().  */ 

begin  proc 

perform  3ql-execute(); 


end  proc 


APPENDIX  D  -  THE  KC  PROGRAM  SPECIFICATIONS 


module  Kernel-Con troller() 

j*  This  procedure  accomplishes  the  following:  */ 

/*  (1)  Initialization  pointers  global  to  the  Kernel  Controller.  */ 

j*  (2)  Checks  si-operation  to  determine  whether  we  are  creating  a  */ 
/*  database,  retrieving  information  from  the  database,  deleting  */ 

j*  information  from  the  database,  inserting  information  into  the  */ 

/*  database,  updating  the  database  or  if  there  are  errors.  */ 

/*  (3)  Depending  on  the  appropriate  operation  the  corresponding  * 

/*  procedure  is  called.  ,  */ 

begin  module 

sql-ptr  =  &(cuser-rel-ptr->ui-li-type.li-sql); 
kc-ptr  =  4i(sql-ptr->si-kc-data.kci-r-kc); 

/*  Initializes  pointers  global  to  the  kernel  controller  */ 

/*  look  at  the  si-operation  to  determine  what  action  to  take  */ 
case  si-operation 

’Create  a  database’: 

perform  load-tables(); 
break; 

’Execute  retrieve  requests’: 

perform  select-requests-handler(); 
break; 

’Execute  retrieve  common  requests’: 

’Execute  delete  requests’: 

’Execute  insert  requests’: 

’Execute  update  requests’: 

perform  rest-requests-handler(); 
break; 

’Otherwise’:  /  *  There  are  errors  *, 

print  error  message; 
break; 

end  case 

end  module 
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proc  yyerror  (s) 
char  *3 
{ 

if  (creating) 
set  CreateDB-error-flag 

print  ("Error  msg  -  tell  user  which  CREATE  TABLE  request  was  in  error") 
free  current  schema  (malloc’d  vars) 
end-if 
else 

free  all  tgt/insert  lists,  temp-str,  and  abdl-strs 
end-else 

reset  all  boolean  and  counter  variables 

}  , 

end-proc  yyerror  ' 


constant:  QUOTE  I  QUOTE 

{ 

literal-const  *  TRUE 
perform  type-checking 

} 

1  INTEGER 
{ 

perform  type-checking 

} 


I:  IDENTIFIER 
I  VALUE 


field-name:  IDENTIFIER 


table-name;  IDENTIFIER 

{  *  '  • 
if  (!  creating) 

if  NOT  valid-table(db,  template) 
print  ("Error  -  relation  name  ’table-name’  does  not  exist") 
perform  yyerror() 
return 
end- if 
end -if 
} 

%% 

end-proc  yyparse 


proc  parser  () 

{ 

if  (!  creating) 

allocate  and  initialize  first  tgt/insert  lists,  temporary-str,  and  abdl-str 
/*  if  an  old  abdl-str  exists,  free  it  first  */' 
end-if 

perform  yyparse() 

reset  all  boolean  and  counter  variables 

} 

end-proc  parser 
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field-spec:  field-name 

I  table-name  DOT  field-name 
{ 

if  (!  valid-attribute(db,  rel,  attr,  attr-len) 
print  ("Error  -  ’rehattr’  is  invalid  combination") 
perform  yy  error  () 
return 
end-if 
if  (join) 

if  (!  or-where)  ||  (  (or-where)  &&  (!  and-where)  ) 
if  (table-name  =  rell) 
rell  -  TRUE 
rel?  =  FALSE 

end-if  « 

if  (table-name  »  rel2) 

*'  rell  FALSE 

rel2  -  TRUE 
end-if 
end-if 

end-if  *.  '  • 

} 


set-fn:  AVG  i  MAX  |  MIN  |  SUM  |  COUNT 


from-list:  table-name 

{ 

copy  first  relation  name  to  templates 
if  (tgt-list  =  null) 

fill  tgt-list  with  "all"  attribute  names  in  the  relation 
end-if 
} 

!  from-list  COMMA  table-name 

{ 

copy  second  relation  name  to  templates 
join  =  TRUE 
allocate  join-str 
} 


empty: 


entry- list:  entry 

{ 

/*  copy  first  value  to  insert-list  */ 
insert- list-length-r -t- 
if  (’entry [0]’  *  QUOTE) 
strip  quotes  from  entry 
change  entry  to  ALPHANUMFIRST 
end-if 

copy  result,  or  original  entry,  to  insert-list 

} 

I  entry-list  COMMA  entry 
{ 

/*  copy,  successive  value(s)  to  insert-list  */ 
insert-list-length-t"t- 
,•  if  (’entryfO)’  »  QUOTE) 
strip  quotes  from  entry 
change  entry  to  ALPHANUMFIRST 
end-if 

copy  result,  or  original  entry,  to  insert-list 

}  *.  V. 


entry;  constant 


expr:  arith-term 

1  expr  ADDOP  arith-term 


arith-term:  arith-factor 

I  arith-term  MULT-OP  arith-factor 


arith-factor;  H  primary 


H:  empty 
i  ADDOP 


primary:  field-spec 

set-fn  LPAR  field-name  RPAR 
1  LPAR  expr  RPAR 
I  constant 

t 

field-spec-list;  field-spec 
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literal:  lit-tuple 

I  LPAR  entry-list  RPAR 
{ 

set-member  *  TRUE 
case  (set-membership-op) 

3,5.8.10:  /*  <-ANY,  <ANY,  >=ALL,  >ALL  */ 

cat  ’max  of  value  set’  to  temporary-str 
4, 6, 7, 9  :  /*  >*ANY,  >ANY,  <=ALL,  <ALL  */ 

cat  ’min  of  value  set’  to  temporary-str 
1  :  /*  NOT  IN  7 

cat  first  value  to  temporary-str 
while  (other  values  exist) 

cat  ")  and  (’attr-name’  /-»  ’value”'  to  temporary-str 
end-while  ' 

0,2  :  /*  IN,  /*ANY  */ 

cat  first  value  to  temporary-str 
if  (more  values  exist) 
abdl-str(llj  =  ’(’ 
or-where  =  TRUE 
end-if* 

while  (other  values  exist) 

cat  ”))  or  ((TEMPLATE  =  ’rel-name’)  and  (’attr-name’" 
to  temporary-str 
if  (  rel-op  =  IN  ) 
cat  "  =•  "  to  temporary-str 
end-if 
else 

cat  "  /=«  "  to  temporary-str 
end-else 

cat  value  to  temporary-str 
end-while 
end-case 

1 


lit-tuple:  entry 

'  LWEDGE  entry-list  RWEDGE 


table-spec:  literal 

{ 

if  (!  set-member) 
if  (’UteraljOl’  -  QUOTE) 
strip  quotes  from  literal 
change  literal  to  ALPHANUMFIRST 
literal-const  =  FALSE 
end- if 

cat  result,  or  original  literal,  to  temporary-str 
if  (nested) 

set  flrst-ptr  to  top  of  abdl-str  list 
end- if 
end-if 

else  « 

set-member  ”  FALSE 
end-else 

} 

!  query-expr 

{ 

increment  per  to  ne^t  tgt/insert  list,  temp-str,  and  abdl-str 
}  • 

I  LPAR  query-expr  RPAR 

{ 

increment  ptr  to  next  tgt/insert  list,  temp-str,  and  abdl-str 

} 

1  «xpr 

{ 

common-attr  =  TRUE 

} 


comparison:  comp-op 

{ 

if  (!  join) 

cat  ’comp-op’  to  temporary -str 
if  (nested) 

copy  type-op-code  to  abdl-str,rel-op 
end- if 
end-if 

} 

> 

comp-op:  EQ 
I  M  J 
{ 

if  (nested) 

cat  ’J’  to  ’M’  and  save 
end-if 

} 

I  L 

{  V  V.  . 

nested  =  TRUE 

} 


J:  empty 

I  K 

{ 

nested  =  TRUE 

} 


K:  ANY  I  ALL 


L:  IN  1  NOT  IN 


M:  NE  !  RWEDGE  1  GE  |  LWEDGE  i  LE 
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boolean-primary:  predicate 


predicate:  expr 

{ 

if  (!  join) 

if  NOT  valid-attribute{db,  template,  attribute,  attr-len) 
print  ("Error  -  field  name  ’attribute-name’  does  not  exist") 
perform  yyerror() 
return 
end-if 

if  (!  and-where) 

allocate  new  temporary- str  « 

end-if 

cat  "(’attribute-name’  "  to  temporary-str  . 
and-where  *  FALSE 
end-if 
else 

save  ’type’. for  later  comparison  during  type-checking, 
in  case  this'  is  the  COMMON  attribute  predicate 
end-else 

} 

comparison 

{ 

if  (nested) 

save  attr  name  in  case  nest  is  actually  a  set  membership  op 
end-if 
} 

table-spec 
if  (!  join) 

cat  ")"  to  temporary-str 
end-if 
else 

if  (common-attr) 

save  values  of  ’expr’,  ’comparison’,  II  ’table-spec’ 
for  the  COMMON  expr,  and  type-check  the  two  attr’s 
end-if 

if  (!  and-where)  icic  (!  or-where) 
allocate  initial  temporary-str. 
copy  "("  to  temporary-str 
end-if 
else 

cat  "("  to  temporary-str 
end-else 

cat  "’expr’  ’comparison’  ’table-spec’)"  to  temporary-str 
ehd-else 


boolean-term;  boolean-factor 

{ 

if  (join)  &&  (!  or-where) 
determine  rel  that  curr  predicate  is  assoc’d  with 
if  (rell)  &&  (!  common-attr) 
cat  "(FILE  =  ’rel-namel’)  and"  to  abdl-str 
cat  temporary -str  to  abdl-str 
cat  ”  FILE  =  ’rel-name2’”  to  join-str 
end-if 

if  (rel2)  icic  (!  common-attr) 
cat  "(FILE  =  ’rel-name2’)  and"  to  join-str 
cat  temporary-str  to  join-str 
cat  "  FILE  =  ’rel-namel’"  to  abdl-str « 
end-if 

if  (common-attr) 

cat  "  FILE  =  ’rel-namel/2"  to  abdl/join-str’s 
end-if 
end-if 

I  boolean-lerm  AND* 

{ 

and-where  =  TRUE; 
if  (!  join) 

cat  "and"  to  temporary-str 
end-if 
} 

boolean-factor 

{ 

if  (join)  &&  (!  or-where)  &&  (!  common-attr) 
if  (rell) 

abdl-3tr[ll  +  3]  =  ’(’ 
cat  ")  and"  to  abdl-str 
cat  temporary-str  to  abdl-str 
end-if 
if  (rel2) 

join-str[ll  -I-  3j  =  ’(’ 
cat  ")  and"  to  join-str 
cat  temporary-str  to  join-str 
end-if 

copy  empty-str  to  temporzwy-str 
and-where  =  FALSE 
end-if 
} 


boolean-factor:  boolean-primary 


boolean:  boolean-term 

{ 

if  (!  join) 

cat  "-(FILE  »  ’relation-name’)  and"  to  abdl-str 
cat  temporary-str  to  abdl-str 
end-if 

} 

I  boolean  OR 
{ 

or-where  *  TRUE 
if  (!  join) 
abdl-str[lll  =  ’(’ 

cat  ")  or  ((FILE  *  ’relation-name’)  and"  to  abdl-str 
copy  empty-str  to  temporary-str  • 

end-if 

} 

boolean-term 

{ 

if  (!  join) 

cat  tempbrarj-str  to' abdl-str 
end-if 
else 

If  (current  predicate  assoc’d  w/same  rel  as  previous  predicate) 
aMl/join-str[n]  =  ’(’ 

cat  ")  or  ((FILE  ==  ’rel-name’)  and"  to  abdl/join-str  (as  appro 
cat  temporary-str  to  appropriate  str  (abdl/join-str) 
end-if 
else 

abdl/join-str(as  approp)[l-l  3j  =*  ’(’ 
cat  "and"  to  appropriate  str  (abdl/join-str) 
cat  temporary-str  to  appropriate  str  (abdl/join-str) 
end-else 

copy  empty  str  to  temporary-str 
or-where  =  FALSE 
end-else 


field-defn:  field-name  LPAR  ty^  G  RPAR 

{ 

create  new  attribute  block 
enter  ’attribute-name’  in  attribute  block 
} 


G:  empty 

{ 

set  key-flag  to  ’0’  in  attribute  block 

} 

!  COMMA  NONULL 

set  key-flag  to  ’1’  in  attribute  block 

t 

type:  CHAR  LPAR  INTEGER  RPAR 

{  .... 

enter  attribute  type  and 'length  in  attribute  block 

} 

;  INT  LPAR  INTEGER  RPAR 

{ 

enter  attribute  type  and  length  in  attribute  block 

} 

FLOAT  LPAR  INTEGER  RPAR 

{ 

enter  attribute  type  and  length  in  attribute  block 


set-clause-list:  set-clause 


set-clause:  SET  (ield-name  EQ  expr 

{ 

if  NOr  validattribute(db,  template,  attribute,  attr-len) 
print  ("Error  -  field  name  ’attribute-name’  does  not  exist") 
perform  yyerror() 
return 
end-if 
else 

copy  "< ’field-name  =*  expr’>"  to  abdl-str 
end-els^ 

}  ' 


ddl-statement:  create-table 


create-table:  CREATE 

{ 

creating  =  TRUE 
locate  db-id  schema  header 
} 

Table  table-name  COLON 

{ 

no-templates  ++ 
create  new  template  block 
enter  ’relation-name’  in  template  block 
} 

field-defn-list 


field-defn-list:  field-defn 

{ 

no-attributes  ++ 

} 

I  field-defn-list  COMMA  field-defn 

{ 

no-attributes  -r-r 


proc  select-requests-handJerO 


j*  This  procedure  accomplishes  the  following;  */ 

/*  (1)  Determines  if  we  have  a  series  of  requests  which  */ 

/*  corresponds  to  a  nested  select  in  SQL.  */ 

/*  (2)  If  we  do  have  a  series  of  requests  we  process  the  first  */ 

/*  request  because  this  is  the  only  fully  formed  ABDL  */ 

/*  request.  This  is  accomplished  by  calling  sql-execute().  * ! 

/*  (3)  If  it  is  a  nested  select,  we  enter  a  loop  to  process  the  */ 

/*  remaining  requests.  Note  that  it  may  be  necessary  to  */ 

/*  process  sub-requests.  This  requires  entering  another  */ 
j*  loop  to  process  these.  This  occurs  when  the  number  of  */ 

/*  responses  to  a  request  is  larger  than  NUM-CONJ.  In  this  */ 

/*  situation  a  request  contains  at  most  NL'M-CCINJ  vdues.  */ 
/*  ^(4)  If  it  is  not  a  nested  select,  then  only  one  request  */ 

/*'*  requires  processing.  This  is  accomplished  by  calling  */ 

/*  sql-execute.  */ 

begin  proc 

curr-req  =  &(sqh:ptr7>si-ab41-tran->ti-curr-req); 

/*  Set  curr-req  equal  to  the  first  request  to  be  processed  */ 
num-reqs  =  <k(sql-ptr->si-abdl-tran->ti-no-req); 

/*  Set  num-reqs  equal  to  the  number  of  requests  to  be  processed  */ 
kc-ptr->kcri-file-status  =  FIRSTTIME; 

/*  Set  the  file  status  to  indicate  it  is  the  first  time  through  */ 
kc-f  tr->kcri-req-status  =  FIRSTTIME; 

/*  Set  the  request  status  to  indicate  it  is  the  first  time  through  */ 
kc-ptr->kcri-num-values-ffile  =  0; 

/*  Set  the  number  of  values  in  the  file  to  zero  *  j 
strcpy(kc-ptr->kcri-fi]es.nri-futr.fi-fname,  CURRFName); 

/*  Assigns  filename  for  the  current  file  */ 
strcpy  (kc-ptr->kcri-files.nri-curr.fi-fname,  FUTRF.Name); 

/*  Assigns  filename  for  the  future  file  */ 

*num-reqs  =  *num-reqs  -  1;  /*  Decrement  num-reqs  */ 
if  (* num-reqs  ==  0)  /*  Its  the  last  subrequest  */ 
sql-ptr->3i-subreq-stat  =  LASTSUBREQ; 
else  /*  Its  an  intermediate  subrequests  */ 
sql-ptr->si-subreq-stat  =  INTERSUBREQ; 

perform  sql-execute();  /*  Handles  the  first  request  */ 


while  (*num-reqs  >  0)  /*  It  is  a  nested  select  * ! 
begin  while 

*num-reqs  =  *num-reqs  -  1;  /*  Decrement  num-reqs  */ 
perform  swap*files{);  /*  Swap  current  and  future  files  *  j 
kc-ptr->kcri-num-values-cfile  =  kc-ptr->kcri-num-values-ffile; 

/*  Set  the  number  of  values  in  the  current  file  * / 
kc-ptr->kcri-num-values-ffile  =  0; 

/*  Reinitializes  the  number  of  values  in  the  future  file  *  j 
kc-ptr->kcri-file-status  =  FIRSTTIME;  /*  Reintialize  the  status  * / 
sql-ptr->si-subreq-stat  =  INTERSUBREQ;  /*  Reinitialization  the  status*/ 
curr-req->ri-ab-req  =  curr-req->ri-ab-req->ari-next-req; 

/*  Advance  pointer  so  it  points  to  the  next  request  */ 
kc-ptr->kcri-unfin-ret  =  curr-req->ri-ab-req->ari-req; 

/*  Loads  abdl  request  template  into  unfin-ret  «/ 
curr-req->ri-ab-req->ari-req  —  NULL; 

*'  /*  Sets  ari-req  to  empty  so  that  the  completed  request  can  */ 

/*  be  built  into  ari-req  */ 

kc-ptr->kcri-req-status  =  FIRSTTIME;  /*  Reinitialize  request  status  */ 
one-conj-fiag  =  FALSE; 

/*  Sets  flag^to  indicate  it  is  not  a  one  conjunction  type  req  */ 

while  ((kc-ptr->kcri-num-values-cfile  >  0)  &&  (  lone-conj-fiag  )) 

/*  There  are  values  left  to  insert  into  the  request  */ 
begin  while 

perform  build-request (  &one-conj-fiag  ); 

!*  Builds  the  next  request  */ 
perform  sql-execute{); 

/*  Handles  the  request  Just  built  */  • 
perform  free(  curr-req->ri-ab-req->  ari-req  ); 

/*  Frees  ari-req  */ 

curr-req->ri-ab-req->ari-req  =  NULL; 

/*  Reinitializes  ari-req  */ 
end  while 

/*  Sets  up  for  the  next  request  */ 
curr- req- >ri-ab-req->  ari-req  =  kc-ptr->kcri-unfin-ret; 

/*  Set  ari-req  equal  to  unfin-ret;  */ 
kc-ptr->kcri-unfin-ret  =  NULL; 

/*  Reinitailize  unfin-ret  */ 
perform  fclose(kc-ptr->kcri-files.nri-curr.fi-fid); 

/*  Close  the  current  file  */ 
end  while 
end  proc 
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proc  sql-execute() 

/*  This  procedure  accomplishes  the  following:  */ 

/*  (1)  Sends  the  request  to  MBDS  using  TI-S$TrafUnit()  " 
/*  which  is  defined  in  the  Test  Interface.  */ 

/*  (2)  Calls  sql-requests-left()  to  ensure  that  all  requests  */ 

/*  have  been  processed.  */ 

/*  (3)  Calls  TI-finish()  for  post  operation  processing.  */ 

begin  proc 

perform  Tl-S$TrafUnit(sql-ptr->3i-curr-db.cdi-dbn2une, 

‘  sql-ptr->si-abdl-tran->ti-curr'req.ri-ab-req->ari-req): 
I*  Sends  the  request  to  MBDS  * /  ? 

perform  sql-chk-responses-left();  ^ 

/*  Wait  until  2dl  responses  have  been  returned  */ 

perform  TI-finish()-, 

/*  Routine  to  tidy-.things  up  after  processing  is  completed  * / 


proc  3q]-chk-respons€s-left() 


/*  This  procedure  accomplishes  the  following;  */ 

/*  (1)  Receives  the  message  from  MBDS  by  calling  */ 

/*  TI-R$Message{)  which  is  defined  in  the  Test  Int.  */ 

/*  (2)  Gets  the  message  type  by  calling  TI-R$Type.  */ 

/*  (3)  If  not  all  responses  to  the  request  have  been  */ 

/*  returned,  a  loop  is  entered.  Within  this  loop  a  */ 

/*  case  statement  separates  the  responses  received  by  */ 

/*  message  type.  */ 

/*  (4)  If  the  response  contained  no  errors,  then  procedure  */ 

/*  Tl-R$Req-res()  is  called  to  receive  the  response  from  */ 

!*  MBDS.  V 

/*  (5)  A  check  is  then  made  to  deterniine  if  this  is  the  last  */ 

/*-\  response.  If  it  is,  then  the  results  are  returned  fo  */ 

/*  the  calling  routine.  If  it  was  not  the  last  response  * / 

!*  then  the  results  are  filed  in  future- results-file.  */ 

/*  (6)  If  the  message  contained  an  error  then  procedure  */ 

/*  TI-RSErrorMessage  is  called  to  get  the  error  message  * / 

/*  and  then  procedure  TI-ErrRes-output  is  called  to  */ 

/*  output  the  error  mesage.  */ 

begin  proc 

num-reqs  =  &(sql-ptr->si-abdl-tran->ti-no-req); 

/*  Number  of  requests  left,  not  counting  the  request  */ 

/*  currently  being  worked  on.  */ 

response  =  3ql-ptr->si-kfs-data.kfsi-rel.kri-response; 

/*  Initailize  response  */ 

done  =  FALfSE;  /*  Initialize  flag  * / 

while  (  not  done  ) 

/*  Not  all  responses  for  the  current  request  have  been  received  */ 
perform  TI-R$Message();  /*  Receive  message  from  MBDS  */ 
msg-type  =  TI-R$Type();  /*  Get  the  type  of  the  received  message 


case  msg'type  /*  Is  the  response  correct  or  are  there  errors?  */ 


’CH-ReqRes’:  /*  The  response  is  correct  */ 
done  «  chk-if*last-response(); 

/*  Set  flag  if  its  the  last  response  */ 

case  sql-ptr->si-operation 

'Execute  Retrieve  Requests’; 

’Execute  Retrieve  Common  Requests’: 
if  (*nuin-reqs  ==  0) 

/*  If  there  are  no  requests  left,  send  the  results  to  */ 

/*  the  formatter.  */ 

Kfs();  •  : 

else 

/’"There  are  requests  left  the  in  nested  select  to  process  */ 
file-future-results();  Save  the  results  */ 
break: 

’Execute  Delete  Requtets’: 
print  "Delete  Query  Done"; 
break; 

’Execute  Insert  Requests’: 
print  "Insert  Query  Done"; 
break; 

’Execute  Update  Requests’: 
print  "Modify  Query  Done"; 
break; 

end  case 
break; 

’Requests  With  Errors’: 
perform  TI- R $ ErrorMessage ( request ,er r-msg) ; 

/*  Get  the  error  message  */ 
perform  TI-ErrRes-output(request,err-msg); 

f*  Output  the  error  message  */ 
done  =  TRUE;  /*  Set  the  flag  */ 
break; 

end  case 
end  while 
end  proc 


proc  build-request(  one-conj-flag  ) 

/*  This  procedure  ^u:complishes  the  following;  */ 

/*  (1)  Builds  the  next  ABDL  request  to  be  processed  by  */ 

/*  calling  either  N-Conjunction,  Not-In-Conjunction  or  */ 

/*  One-conjunction  depending  on  the  relational  operator.  */ 

/*  (2)  Sets  one-conj-flag  if  procedure  One-Conjunction  is  *  j 

r  called.  V 

begin  proc 

curr-abdl-req  =  &(sql-ptr->si-abdl-tran->ti-curr-req); 

/*  Gets  the  current  ABDL  request  */  , 

% 

c^e  curr-abdl-req->ri-ab-req->ari-rel-op  ' 

I*  Switches  based  upon  the  relational  operator  in  the  request  * f 

Tn  Operator’: 

perform  N-Conjunction(); 
break;  -  . .  . 

’Not  In  Operator’: 

perform  Not-In-Conjunction(); 
break; 

’Not  Equal  to  Any  Operator’: 
perform  N-Conjunction(); 
break; 

’Less  than  or  Equal  to  Any  Operator’: 

perform  One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int); 

*one-conj-flag  =  TRUE; 
break; 

’Greater  than  of  Equal  to  Any  Operator’: 

perform  One-Conjunction(kc-ptr->kcri-min.mini-val.dvi-int); 

*one-conj-flag  =  TRUE; 
break; 

’Less  than  Any  Operator’: 

perform  One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int); 

*one-conj-flag  =  TRUE; 
break: 
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’Grater  than  Any  Operator’: 

perform  On e-Conj un ction  ( kc-p  tr-  >  kcri-min . mini- val.d v i- in t ) ; 

*one-conj-flag  =•  TRUE; 

break; 

’Less  than  or  Equal  to  All  Operator’; 

perform  One-Conjunction(kc-ptr->kcri-min.mini-v2d.dvi-int); 

*one-conj-flag  =  TRUE; 

break; 

’Greater  than  or  Equal  to  All  Operator’: 

perform  One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int); 

*  one-con  j-flag  »  TRUE;  * 

break;  * 

’Less  than  All  Operator’: 

perfrom  One-Conjunction(kc-ptr->kcri-min.mini-val.dvi-int); 

*  one-con  j-flag  »  TRUE; 

break;  .  . 

’Greater  than  All  Operator’: 

perform  One-Conjunction(kc-ptr->kcri-max.maxi-val.dvi-int); 

*  one-con  j-flag  =  TRUE; 
break; 

end  case 
end  proc 
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proc  N-Conjunction() 


/*  This  procedure  accomplishes  the  following:  */ 

/*  (1)  Builds  an  N  conjunction  ABDL  request  using  a  template  */ 

/*  (the  unfinished  return)  provided  by  KMS.  * / 

/*  (2)  This  is  accomplished  by  loading  in  the  action  portion  of  */ 

/*  the  template,  loading  up  to  NUM-CONJ  conjunctions  into  */ 

/*  the  request,  ’oring’  the  conjunctions  together  and  then  */ 

!*  adding  the  target  list.  */ 

/*  (3)  The  conjunction  portion  is  formed  by  copying  from  the  * / 

/*  beginning  of  the  conjunction  to  first  asterik  of  the  * / 

/*  template  into  ari  request.  Then  the  next  value  from  the  */ 

/*  the  current  file  is  inserted  into  the  ari  request^  */ 

/*  followed  by  the  remainder  of  the  conjunction.*  If  this  */ 

/*.'  is  not  the  last  conjunction  of  the  .-equest,  then  an  or  */ 

/**  is  inserted  and  the  next  conjunction  is  constructed  using  * / 

/*  the  same  process.  */ 

begin  proc 

abdl-ptr  =•  sql-ptr'>si-abdl-tran->ti-curr-req.ri-ab-req; 

/*  Set  pointer  to  the  current  ABDL  request  * / 

if  (kc-ptr->kcri-req-status  FIRSTTIME) 

/*  Calculates  values  that  will  be  used  on  all  calls  to  this  procedure  */ 

/*  for  a  given  request.  Thus,  these  values  are  only  calculated  once.  */ 

begin  if 

for  (i  =>  0;  kc-ptr->kcri-unfin-ret[i]  !=  LPARAN;  i++) 

kc-ptr-> kcri-beg-conj  =  ij/^Mark  position  where  the  conjunction  begins 
action-len  *  kc-ptr->kcri-beg-conj;/*does  not  include  1st  LPARAN  */ 
for  (  ;  kc-ptr->kcri-unfin-ret[ij  !*=  ASTERIK;  i++) 

» 

kc-ptr->kcri-beg-asterik  =  i;/*Mark  position  of  the  first  asterik*/ 
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j*  Calculates  the  size  of  the  template.  *  j 
unfin-ret-len  =  strlen(kc-ptr->kcri-unfin-ret); 
for  (i  —  unfin-ret-len;  kc-ptr->kcri-unfin-ret[i]  ASTERIK;  i~) 
» 

kc-ptr->kcri-end-asterik  =  i;/*Mark  position  of  last  asterik*/ 
for  (  ;  kc-ptr->kcri-unfin-ret[i|  !=  LPARAN;  i-l--!-) 

for  (  ;  kc-ptr->kcri-unfin-ret[il  !=  RPARAN;  i— ) 

J 

kc-ptr->kcri-end-conj  =  i; 

/*Meu'k  position  of  the  end  of  the  conjunction*/ 
target-len  =  unfin-ret-len  -  kc-ptr->kcri-end-conj  +  1; 
conj-len  unfin-ret-len  -  target-len  -  action-len; 

% 

.  /*  Calculates  the  maximum  length  of  the  finished  request.  */ 
kc-ptr->kcri-req-len  =  (action-len  -I-  (NUM-CONJ  *  conj-len)  ■+■ 
(NUM-CONJ  *  ORLen)  -I-  target-len); 
kc-ptr->  kcri-files.nri-curr.fi- fid  = 
fopen(kc-ptr->  kcri-files.nri-curr.fi-fname,  "r”); 
kc-ptr->kcri- req-status  =  RESTTIME; 

end  if 
else 

begin  else 

/*  Reset  the  length  of  the  unfinished  request  */ 
unfin-ret-len  =  strlen(kc-ptr->kcri-unfin-ret); 
end  else 

/*  Allocates  space  for  the  finished  request.  */ 
abdl-ptr->ari-req  =  var-str-alloc(kc-ptr->kcri-req-len); 

/*  load  request  with  action  portion  and  an  (  */ 
for  (i  =  0;  i  !=  (kc-ptr->kcri-beg-conj  +  1);  i-)— h) 
abdl-ptr->ari-req[i]  =  kc-ptr->kcri-unfin-ret[i]; 

j  =  i; 
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counter  »  1; 

while  ((counter  <=  NUM-CONJ)  Scic.  (kc-ptr->kcri-nunl-values-cfile  !=  0)) 
/’*Keep  building  conjunctions,  filling  them  with  values 
ii  ’oring’  them  together*/ 

begin  while 

/*  loads  template  up  to  asterik  */ 

for  (i  «  kc-ptr->kcri-beg-conj;  i  !=  kc-ptr'>kcri-beg-asterik;  i++) 
begin  for 

abdl-ptr->ari-req[j]  “  kc-ptr->kcri-unfin-ret[i]; 
end  for 

/*  loads  in  the  next  value  */  * 

for  (i  “  0;  ((abdl-ptr->ari-req[jl  = 

getc(kc-ptr->kcri-files.nri-curr.fi-fid))  1=  ’0);  i-l-+) 

j+'i"; 

/*  loads  the  appropriate  number  of )  behind  the  conj  */ 
for  (i  *  (kc-ptr->kcri-end-asterik  +  1); 

i  !“  (kc-ptr->kcri-end-conj  +  1);  i-r+) 
begin  for 

abdl-ptr->ari-req(jj  =  kc-ptr->kcri-unfin-ret[ij; 
end  for 

if  ((counter  !=  NUM-CONJ)  &&  (kc-ptr->kcri-num-values-cfile  !*  1)) 

/*  It  is  not  the  last  conjunction  */ 

begin  if 

/*  loads  "  or  ”  into  the  request  to  connect  the  conjs  */ 
abdl-ptr->ari-req(j-r-l-]  =  BLANKSPACE; 
abdl-ptr->ari-req[j-i— )-j  =  'o’; 
abdl-ptr->ari-reqij+-t-j  =  ’r’; 
abdl-ptr->ari-req[j-t— h]  =  BLANKSPACE; 
end  if 


else  /*  It  is  the  last  conjunction  * / 


begin  else 

/*  loads  the  t£urget  list  one  value  oer  line  */ 
for  (i  =  (kc-ptr->kcri-end-conJ);  i  !=  (unfin-ret-Ien  +  1);  i-*— r) 
begin  for 

abdl-ptr->ari'req[j]  =  kC'ptr->  kcri-unfin-retli:; 
end  for 

/*  checks  if  there  is  only  one  value  in  this  request.  * / 

/*  if  true  then  one  set  of  parenthesis  is  replaced  with  blanks  */ 
if  (counter  *=  1) 

begin  if  J 

abdl-ptr->ari-req[kc-ptr->kcri-beg-conj]  =  BLANKSPACE; 
abdl-ptr->ari-req[kc-ptr->kcri-end-conj]  =  BLANKSPACE; 
end  if 

end  else 

counter'i-+; 

kc-ptr->kcri-num-values-cfile“; 
end  while 

if  (kc-ptr->kcri-num-values-cfile  ==—  0) 

/*  Set  the  status  to  signify  the  last  subrequest  *  / 
3ql-ptr->3i-subreq-stat  =  LASTSUBREQ; 

end  proc 


proc  Not-In-Conjuiiction() 


/*  This  procedure  etccomplishes  the  following;  */ 

/*  (1)  Builds  a  one  conjunction  ABDL  request  using  a  template  * ! 

/*  provided  by  KMS.  */ 

/*  (2)  This  is  accomplished  by  loading  in  the  action  portion  of  */ 

/*  the  template,  leading  up  to  NUM-CONJ  conjunctions  into  * j 
/*  the  request,  ’anding’  the  conjunctions  together  and  then  */ 

/*  adding  the  target  list.  *  j 

/*  (3)  The  conjunction  portion  is  formed  by  copying  from  the  * / 

/*  beginning  of  the  conjunction  to  first  aster ik  of  the  */ 

/*  template  into  ari  request.  Then  the  next  value  from  the  */ 

/*  the  current  file  is  inserted  into  the  ari  request,  */ 

/•  followed  by  the  remainder  of  the  conjunction.*  K  this  */ 

/*;'  is  not  the  last  conjunction  of  the  request,  then  m  and  */ 

/*  is  inserted  and  the  next  conjunction  is  constructed  */ 

/*  using  the  same  process.  *  / 

begin  proc 

abdl-ptr  =  sql*ptr->si-abdl-tran->ti-curr-req.ri-ab-req; 

/*  Set  pointer  to  the  current  ABDL  request  */ 

if  {kc-ptr->kcri-req-status  «=  FIRSTTIME) 

/*  Calculates  values  that  will  be  used  on  all  calls  to  this  for  a  */ 

/*  given  request.  Thus,  these  values  are  only  calculated  once.  */ 

begin  if 

for  (i  =  0-,  kc-ptr->kcri-unfin-ret[i]  !=  ASTERIK;  i++) 

t 

kc-ptr->kcri-b€g-asterik  =  i;/*Mark  position  of  first  asterik*/ 
for  (  ;  kc-ptr->kcri-unfin-ret[ij  !=  LPARAN;  i~) 

t 

kc-ptr->kcri-beg-conj  =  i;/*Mark  position  where  conjunction  begins* 

/*  Calculates  the  size  of  the  template  */ 

unfin-ret-len  =  strlen(kc-ptr->kcri-unfin-ret); 

for  (i  =  unfin-ret-len;  kc-ptr->kcri-unfin-retfii  !=  ASTERIK;  i— ) 

kc-ptr-> kcri-end-asterik  =  i;/*Mark  position  of  the  last  asterik* 
for  (  ;  kc-ptr->kcri-unfin-retiij  !=  RPARAN;  i-^ — ) 

kc-ptr->kcri-end-conj  ■=  i: 

/*  Mark  position  where  the  conjunction  ends  */ 


action-len  =  kc-ptp->kcri-beg-conj; 

target-len  =  unfin-ret-len  -  kc-ptr->kcri-end-conj; 

conj-len  =  unfin-ret-len  -  target-len  -  action-len; 

/*  Calculates  the  maximum  length  of  the  finished  request.  */ 
kc-ptr->kcri-req-len  =  (action-len  +  (NUM-CONJ  *  conj-len) 
(NUM-CONJ  *  ANDLen)  +  target-len); 
kc-ptr->kcri-files.nri-curr.fi-fid  = 
fopen(kc-ptr->kcri-files.nri-curr.fi-fname,  "r”); 
kc-ptr->kcri-req-status  =  RESTTIME; 
end  if 
else 

begin  else  « 

/*  Reset  the  length  of  the  unfinished  request  */* 
unfin-ret-len  *  strJen(kc-ptr->kcri-unfin-ret); 
end  else 

/*  Allocates  space  for  the  finished  request  */ 
abdl-ptr->ari-req  =  var-str-alloc(kc-ptr->kcri-req-len); 

/*  load  request  with  action  portion  and  an  (  */ 
for  (i  ==  0;  i  !=  (kc-ptr->kcri-beg-conj);  i-t-H-) 
abdl-ptr->ari-req[i]  =  kc-ptr->kcri-unfin-ret(i]; 

j  =  i: 

counter  =  1; 

while  ((counter  <==  NUM-CONJ)  &&  (kc-ptr->kcri-num-values-cfile  !=  0)) 
/*  Keeps  building  conjunctions,  filling  them  with  values  and  */ 

/*  ’anding’  them  together.  */ 

begin  while 

/*  loads  template  up  to  asterik  */ 

for  (i  =  kc-ptr->kcri-beg-conj;  i  !=  kc-ptr->kcri-beg-asterik;  i-^-^n) 
begin  for 

abdl-ptr->ari-req!j)  =  kc-ptr->kcri-unfin-ret[ij; 
j+-!-: 
end  for 
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/*  loads  in  next  value  */ 

for  (i  =  0;  ((abdl-ptr->ari-req[jl  == 

getc(kc-ptr->kcri-files.nri'curr.fi-fid)]  .'=  ’0);  i-r-r) 

j++; 

/*  loads  a  )  behind  the  conjunction  */ 

abdl-ptr->ari-req[jj  =  kc-ptr->kcri-unfin-ret[kc-ptr->  kcri-end-conjj; 

j-^ 

if  ((counter  !=  NUM-CONJ)  (kc-ptr->kcri-num-values-crile  !=  1)) 
/*  It  is  not  the  l2ist  conjunction  */ 
begin  if 

/*  loads  "  and  ”  into  the  request  to  connect  Jhe  conjs  */ 
abdl-ptr'>ari-req(j++]  =  BLANKS  PACE;  ' 
abdl-ptr'>ari-req[j4-(-l  =  ’a’; 
abdl-ptr->ari-req{j+-l-]  =  ’n’; 
abdl-ptr->ari-req(j++]  =  ’d’; 
abdl-ptr->ari-req[j-+-+j  =  BLANKSPACE; 
end  if 

^  ,  • 

else  /*  It  is  the  last  conjunction  */ 
begin  else 

/*  loads  the  target  list  including  a  */ 

for  (i  =  (kc-ptr->kcri-end-conj  +  1);  i  !=  (unfin-ret-len  4-  1);  i+-i-) 
begin  for 

abdl-ptr->ari-req[j]  =  kc-ptr->kcri-unfin-ret(i]; 

j^+; 

end  for 
end  else 
counter-h- h; 

kc-ptr-  >  kcri-num- values-cfile—; 
end  while 

if  (kc-ptr- >kcri-num-values-cfile  ==  0) 

/*  Set  the  status  to  signify  the  last  subrequest  */ 
sql-ptr->si-subreq-stat  =  LASTSUBREQ; 


end  proc 


Enter  type  o-f  operation  desired 
<1)  —  load  a  new  database 
<p)  -  process  old  database 
(x)  -  return  to  the  operating  system 

ACTION  - > 

Upon  selecting  the  desired  operation,  the  user  will 
be  prompted  to  enter  the  name  o-f  the  database  to  be  used. 
For  the  case  that  the  load  operation  was  selected,  the 
database  name  provided.  cannot^  be  presently  used. 
Likewise,  for  a  process  old  operation  the  database  name 
provided  must  be  in  existence.  In  either  case,  if  an 
error  occurs  the  user  will  be  told  to  rekey  a  different 
name.  The  session  continues  once  a  valid  name  has  been 
entered. 

For  either  type  of  operation  selected  from  MENUl,  the 
second  menu  is  the  same  and  asks  for  the  mode  of  input. 
This  input  may  come  from  a  data  file  or  interactively 
from  the  terminal.  The  generic  menu,  called  MENU2,  looks 
like  the  following: 

Enter  mode  of  input  desired 

(f)  -  read  in  a  group  of  transactions  from  a  file 
(t)  -  read  in  transactions  from  the  terminal 
(x)  -  return  to  the  previous  menu 

ACTION  - ■ 

If  the  user  wishes  to  read  transactions  from  a  file  he 
will  be  prompted  to  provide  the  name  of  the  file  that 
contains  those  transact! ons.  If  the  user  wishes  to  enter 
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APPENDIX  F  -  IHE  SQL  USgRS'  MANUAL 


A.  Overview 

The  SQL  language  interface  allows  the  user  to 
input  transactions  from  either  a  file  or  the  terminal.  A 
transaction  can  take  the  form  of  either  creates  of  a  new 
database^  or  queries  against  an  existing  database.  The 

SQL  language  interface  is  menu— driven.  When  the 

% 

% 

transactions  are  read  from  either  a  file  or  the  terminal 
they  are  stored  in  the  interface.  ‘  If  the  transactions 
are  creates  they  are  executed  automatically  by  the  system. 
If  the  transactions  are  queries  the  user  will  be 
prompted  by  another  menu  to  selectively  pick  an  individual 
query  to  be  processed.  The  menus  provide  an  easy  and 
efficient  way  to  allow  the  user  to  see  and  select  the 
methods  in  which  to  perform  the  mapping  functions.  Each 
menu  is  tied  to  its  predecessor  so  that  by  exiting  each 
menu  the  user  is  moved  back  up  the  menu  "tree".  This 

allows  the  user  to  perform  multiple  tasks  in  one  session. 

B.  USING  THE  SYSTEM 

There  are  two  operations  the  user  can  perform  on 
the  database  schemas.  The  user  can  either  create  a  new 
database  or  process  queries  against  an  exist.ng  database. 
The  first  menu  displayed  prompts  the  user  for  which 
function  to  perform.  This  menu,  hereafter  named  MENUl, 
looks  like  the  following: 
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proc  finish() 


/*  procedure  frees  any  structure  space  that  may  have  been  created  */ 
/*  during  the  creation  of  the  ouput  table  */ 

begin  proc 

tbl-ptr  »  current  relational  database; 

tbl-ent-ptr  =  tbl-ptr->thi-first-ent;/*  Set  tbl-ent-ptr  to  the  first 

table  entry  /* 

while  (tbl-ent-ptr  <>  NULL) 
begin 

tbl-ptr- >thi-first-ent  =  tbl-ent-ptr->tei-next; 

/*  Get  the  next  table  entry  */  .  ^ 

tbl-ent-ptr- >tei-next  =  NULL;  ♦ 

free(tabl-ent-ptr); 
tbl-ent-ptr  =»  tbl-ptr- >thi-first-ent; 
end  while 
end  proc 
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proc  more() 

/*  This  procedure  is  jtist  like  the  more  facility  offered  in  Unix  */ 

/*  It  is  not  as  sophisticated,  however.  */ 

begin  proc 

open  kfs-r-ptr->kri-o-file.fi-fname  for  "read"  status; 
get  a  char  from  opened  file; 
while  (NOT  EOF) 
begin 

counter  =  0;  /*  counter  is  used  to  keep  track  of  how  many  lines 
have  been  printed  on  the  screen  */ 
while  ((counter  <=  screen-heigth)  AND  (NOT  EOF)) 
begin 

print  the  char; 
if  (c  =—  carriage  return) 
counter  =  counter  +  1; 
get  a  char  from  opened  file; 
end  while  .... 
if  (counter  >  ‘screen- heigth) 
begin 

print  the  word  "-more—"; 

determine  if  user  wants  to  quit  or  advance  1  to  screen-heigth  lines 
in  the  opened  file; 

end  if 
end  while 
end  proc 

proc  skipnameorval() 

/*  This  procedure  skips  over  either  an  attribute  name  or  attribute  value  */ 

/*  depending  where  kri-curr-pos  is  currently  located.  This  is  necessary  */ 

/*  because  results  are  coming  back  as:  ATTR-NAME  ATTR-VALUE.  In  some  * j 
/*  situations  we  want  just  the  NAME  and  in  others  we  want  just  the  VALUE  */ 

begin  proc 

update  kri-curr-pos  to  skip  over  the  the  attr  name  or  value 
that  it  is  currently  positioned  at; 

end  proc 
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proc  Ioad-titles() 


j*  This  procedure  loads  the  heading  of  a  SQL  results  table  into  the  */ 

/•  output  file  */ 

begin  proc 

tbl-ptr  =  kfs-r'ptr->kri-form-data.thi-rirst-ent; 

/*  Get  the  first  table  entry  so  that  you  can  work  from  here  */ 
while  (tbl-ptr  <>  NULL) 
begin 

column- difference  =»  tbl-ptr- >tei-col-len  -  tbl-ptr->tei-n£une-len; 
j*  column-difference  indicates  the  difference  between  the 
actual  column  length  and  the  length  of  tl)e  attr  value  to 
be  output.  We  need  this  to  determine  hdw  many  spaces  are 
*'  needed  to  keep  our  results  left-justified  *  j  . 

print  the  attr  name; 

print  a  series  of  blank  spaces  equal  to  the  column-difference; 
print  a  ”| "; 

tbl-ptr  =  tbl-j>tr->  tei-next; 
end  while  -  . . 

print  a  carriage  return; 

print  a  series  of  equal  to  the  width  of  the  table; 
end  proc 


proc  get-siae(x) 

/*  This  procedure  obtains  the  maximum  size  that  a  particular  attribute  */ 
/•  value  may  take  on  */ 

char  x; 

begin  proc 

traverse  the  table  entry  list  until  you  find  the  attr  name  equal  to  x; 
retum(the  length  of  this  attr  name); 
end  proc 
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proc  one-hscrecD-resulta() 

I*  This  procedure  outputs  the  results  in  SQL  table  form  if  this  table  *  j 
/*  can  fit  within  the  width  of  one  screen  * / 

begin  proc 

if  (FIRSTBUF  -=  TRUE) 
begin 

proc  load-titles();  /*  Output  the  headings  of  the  table  */ 
kfs-r-ptr->kri-status  =  RESTBUFS;  /*  Change  status  to  indicate 

that  titles/headings  no 
longer  have  to  be  output  */ 

end  if 

while  (kfs-r-ptr->kri-curr-po8  <  kfs-r‘ptr->kri-res-l4n) 

.begin 

*  tbl-ptr  *  kfs-r-ptr->kri-form-data.thi'first-ent; 

/*  Get  the  first  table  entry  so  that  you  can  work  from  here  */ 
while  (tbl-ptr  <>  NULL) 
begin 

proc  skipn^iniMrvalO;; 

column-difierence  =  tbl-ptr- >tei-col-len  -  proc  get-val-lfen(); 

/*  column-difference  indicates  the  difference  between  the 
actual  column  length  and  the  length  of  the  attr  value  to 
be  output.  We  need  this  to  determine  how  many  spaces  are 
needed  to  keep  our  results  left-justified  */ 
print  the  attr  value; 

print  a  series  of  blank  spaces  equal  to  the  column-difference; 
print  a  ”1  ”; 

tbl-ptr  =“  tbl-ptr->tei-next;  /*  Get  the  next  table  entry  */ 
end  while 

print  a  carriage  return; 
end  while 
close  Output  File; 
end  proc 
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proc  lill-table-headings() 

/*  This  procedure  accomplishes  the  following:  */ 

/*  (1)  Fills  different  fields  in  various  structures  so  that  an  */ 
j*  output  table  similiar  to  one  created  in  SQL  can  be  made  */ 

/•  to  show  results  coming  from  MBDS  */ 

begin  proc 

curr-pos  =  kfe-r-ptr->kri-curr-pos;  /*  curr-pos  used  to  hold  actual 

current  position  in  the  results 
buffer  so  that  kri-curr-pos  can 
be  set  back  to  this  value  when  we 
exit  this  procedure  */, 
allocate  a  new  table-entry -info  node;  ' 

read  the  attribute  name  from  the  response  buffer; 

determine  the  length  of  this  name  and  store  in  new-tei-ptr->tei-name-len; 
new-tei-ptr->tei-val-len  =  proc  get-size(new-tei-ptr->tei-attr); 

j*  Get  the  max  size  that  this  attr  can  possibly  take  on  */ 
new-tei-ptr->tei-col-len  =  proc  max(new-tei-ptr->tei-name-len, 

new-tei-ptr->  tei-val-len) ; 

j*  Determine  the  actual  column  size  in  the  output  table  *  j 
thi-first-ent  =  new-tei-ptr;  /*  First  entry  for  output  table  is  equal 

to  the  results  we  just  obtained  *  j 

thi-curr-ent  =  new-tei-ptr;  j*  The  current  entry  is  also  equal  to  these 

results  */ 

proc  skipnameorval();  /*  Skip  over  the  attr  value  in  response  buffer 
until  the  next  attr  name  is  hit  */ 
temp-attr  —  next  attr  name  in  response  buffer; 
while  (temp-attr  <>  thi-first-ent->attr-name) 
begin 

allocate  a  new  table-entry-info  node;  /*i.e.,  new-tei-ptr  * / 
new.tei-ptr->tei-attr  *  temp-attr; 
determine  the  length  of  this  name  and  store 
in  new-tei-ptr->tei-name-len; 

new-tei-ptr->  tei-val-len  =  proc  get-size(new-tei-ptr->tei-attr); 

/*  Get  the  max  size  that  this  attr  can  possibly  take  on  */ 
new-tei-ptr- >tei-col-len  =  proc  max(new-tci-ptr->tei-name-len, 

new-  tei-ptr-  >  tei-val-len) ; 

/*  Determine  the  actual  column  size  in  the  output  table  * / 
tbl-ptr->thi-curr-ent->tei-next  =  new-tei-ptr; 
tbl-ptr->thi-curr-ent  =  new-tei-ptr; 
proc  skipnameorval(); 

temp-attr  =  next  attr  name  in  response  buffer; 
end  while 

kfs-r-ptr->kri-curr-pos  =»  curr-pos;  /*  Restore  current  position  */ 
end  proc 


proc  initialize() 


r 

r 

r 

/• 

r 

/* 

r 

r 


This  procedure  accomplishes  the  following:  */ 

(1)  Sets  kfs-r-ptr  to  the  address  of  the  current  relational  */ 

database  */ 

(2)  Sets  kri-curr-'pos  to  1,  the  starting  point  in  the  response  */ 

buffer  */ 

(3)  If  this  is  the  first  time  for  a  particular  set  of  responses  * ! 

then  an  Output  File  is  opened  for  write  status;  otherwise  * / 
the  Output  File  is  opened  for  append  status  */ 


begin  proc  , 

set  kfs-r-ptr  to  the  address  of  the  current  relational  database; 
l^r-ptr->kri-curr-pos  ■»  1;  /*  Sets  a  pointer  in  the  7esp>onse  array  to 

the  beginning  of  the  array 

if  (kfs-r-ptr- >kri-status  ==«  FIRSTIME)  /*  If  this  is  the  first  time 

that  this  procedure  has  been 
called  for  this  particular 
-  -  ■  response . then .  */ 

begin 

open  Output  File  for  "write”  status; 

kfs-r-ptr- >kri-stat us  =  FIRSTBUF;  /*  Change  status  to  indicate  that 

the  FIRST  BUFFER  is  being 
handled  */ 

end  if 

else 

open  Output  File  for  "append"  status;  /•  This  is  not  the  first  time 

thru  this  procedure  so  we 
need  to  append  the  results 
to  the  results  already  in  the 
Output  File  *  / 


end  proc 


APPENDIX  E  •  THE  KFS  PROGRAM  SPECIFICATIONS 


module  kfs  () 

/*  This  procedure  accomplishes  the  following:  *  I 

/*  (1)  Calls  initializeO  */ 

/*  (2)  Calls  fill-table-headings()  */ 

/*  (3)  Calls  one-hscreen-results()  if  the  width  of  the  */ 

/*  output  table  is  less  than  the  width  of  the  screen  *  j 
/*  (4)  Calls  more()  to  output  the  results  file  if  the  last  */ 

/*  response  buffer  has  been  received.  ,  */ 

/*  (5)  Calls  finish(]  to  free  used  memory  after  the  latft  * / 

/*  response  buffer  has  been  received  *J 

begin  module 

proc  initialize(];  I*  Set  up  structures  and  variables  for  processing  */ 
proc  fill-table-headings();  j*  Get  headings  for  relational  output  */ 
if  (table-width  <=  OutputCols)  /*  If  table  size  <»  screen  width  */ 
proc  one-hscreen-results(); 
else 

proc  all-hscreen-results();  /*  This  procedure  has  not  been  written  */ 
if  (last  response  buffer) 
begin 

proc  more();  /*  Output  relational  output  file  to  screen  */ 
proc  finishO;  /*  Close  out  sturctures  and  variables  and  free  space  * / 
end  if 
end  module 


proc  swap>fUes() 


/*  This  procedure  swaps  the  contents  of  the  future  file  with  the  * 
j*  contents  of  the  current  file.  * ! 

begin  proc 

curr-fp  =*  &(kc-ptr->kcri-files.nri-curr); 
fut-fp  =  &(kc-ptr->kcri-files.nri-futr); 
temp.fi-Hd  =  curr-fp- >fi-fid; 
strcpy(temp.n-fname,  curr-fp->fi-fname); 
curr-fp- >fi-fid  =  fut-fp- >fi-fid; 

strcpy(curr-f^>fi-fname,  fut-fp- >fi-fname);  \ 

fut-fp- >fi-fid  =  temp.fi-fid;  ' 

^rcpy  (fut-fp- >fi-fname,  temp.fi-fname) ; 

end  proc 
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while  (  kc-ptr->kcri-curr-pos  <  (kc-ptr->kcri-res-len)  -  2) 
begin  while 

for  (;response[kc-ptr->kcri-curr-pos]  !=  EMARK;kc-ptr->kcri-curr-pos-i-+) 

;  /*  Skip  the  attribute  name  */ 

(kc-ptr->  kcri-curr-pos) 

for  (val-len  =  O;response[kc-ptr->kcri-curr-pos  -r  val-len]  !=  EMARK; 
val-len  ++) 

;  /*  Find  out  how  long  the  attribute  value  is  */ 

/*  Allocate  storage  space  for  the  value  */ 
temp-str  =  var-str-alloc(val-len  -f-  i); 
j  =  0;  , 

*'  for  (  ;response(kc-ptr->kcri-curr-posj  !=  EMARK;kc-ptr->kcri-curr-pos-r+) 

begin  for 

j*  Load  the  value  into  the  future  file  */ 
putc(response|kc-ptr->kcri-curr-po8],  f-ptr->nri-futr.fi-fid); 

I*  Load  the  v^lue  into  the  temp  string  */ 
temp-str  (j-r-+l  =  response  jkc-ptr->kcri-curr-pos); 
end  for 

(kc-ptr->kcri-curr-pos)+-f; 
putc(’0,  f-ptr->nri-futr.fi-fid); 
temp-str[jl  =  ’ 

*num-value8  =  *num-values  -f  1;  /*  Count  the  number  of  values  */ 

/*  Calculates  the  maximum  value  of  those  values  returned  so  far  */ 
max-ptr->maxi-val.dvi-int  = 

max(max-ptr->maxi-val.dvi-int,  str-to-num( temp-str)); 

/*  Calculates  the  minimum  value  of  those  values  returned  so  far  */ 
min-ptr->mini-val.dvi-int  = 

min(min-ptr->mini-val.dvi-int,  str-to-num(temp>-str)); 
free(temp-str); 
end  while 


fclose(f-ptr->nri-futr.ri-fid); 
end  proc 


proc  file-future-results() 

/*  This  procedure  accomplishes  the  following:  */ 

/*  (1)  Removes  the  attribute  names  from  the  response.  * ; 

/*  (2)  Places  the  remaining  attribute  values  into  the  * / 

/*  future-results-Hle.  */ 

/*  (3)  Keeps  track  of  how  many  sub-requests  there  are.  */ 

/*  (4)  Calculates  and  stores  max  and  min  values.  */ 

begin  proc 

max-ptr  *  &(kc-ptr->kcri-max);  /*  Initialize  pointer  */ 
min-ptr  *  &(kc*-ptr->kcri-min);  /*  Initialize  pointer  */ 
f-ptr  *  &(kc-ptr->kcri-files);  /*  Initialize  pointer  '/ 

if  (kc-ptr->kcri-file-status  FIRSTTIME) 

/*  Do  the  following  initialization  */ 

begin  if 

max-ptr->maxi-val.dvi-int  =  MINVAL; 
min-ptr->mini-val.dvi-int  =  MAXVAL; 
f-ptr- > nri-futr.fi-fid  =  fopen(f-ptr->nri-futr.fi-fname,  ”w"); 
kc-ptr->kcri-file-status  =  RESTTIME; 
end  if 

else 

f-ptr- > nri-futr.fi-fid  =»  fopen (f-ptr- >nri-futr.fi-fname,  "a"); 
kc-ptr->kcri-curr-pos  =  1; 

response  =  sql-ptr->si-kfs-data.kfsi-rel.kri-respon3e; 
kc-ptr->kcri-res-len  =  strl€n(response); 


/*  Number  of  values  in  the  returned  result  of  the  request  */ 
num-values  =  &(kc-ptr->kcri-num-values-ffile); 


j*  loads  the  remainder  of  the  request  including  the  target  list  */ 
for'(i  =*  (kc-ptr->kcri-end-asterik  4-  1); 

i  !=  strlen(kc-ptr->kcri-unfin-ret)  +1;  i+4-) 
begin  for 

abdl-ptr->ari-req[j]  =  kc-ptr->kcri-unfin-ret[i]; 
end  for 

abdl-ptr->ari-req[ji  =  ’ 
sql-pir->si-subreq-stat  =  LASTSUBREQ; 

.end  proc 


proc  chk-if-last-response() 


/*  This  procedure  accomplishes  the  following; 

/*  (1)  Determines  the  length  of  the  response. 

!*  (2)  Determines  if  this  is  the  last  response  to  a  given  request  and 
/*  returns  a  boolean  indicating  such.  */ 


V 

V 


begin  proc 


/*  Calculates  response  length  */ 
for  (response-length  =  0; 

sql-ptr->si-kfs-data.kfsi-rel.kri-response [response-length]  !=  EOResult; 
response-length-l--l-) ; 
t-response-length; 


/*  Checks  if  this  is  the  last  response  */ 

if  (sql-ptr->si-kfs-data.kfsi-rel.kri-response[response-length  -  3] 
==  CSignal) 
return(TRUE); 

else  /*  It  is  not  the  last  response  */ 
return(FALSE); 


end  proc 


proc  One-Conjunction  (value) 


/*  This  procedure  accomplishes  the  following:  */ 

/*  (1)  Builds  a  one  conjunction  ABDL  request  using  a  template  *  j 

/*  provided  by  KMS.  *  / 

/*  (2)  This  is  accomplished  by  loading  in  the  unfinished  return  */ 

/*  up  to  the  first  asterilc,  loading  in  the  value  passed  to  */ 

/*  the  procedure  and  then  loading  in  the  remainder  of  the  */ 

/*  of  the  unfinished  return.  * / 

begin  proc  « 

abdl-ptr  =  sql-ptr->si-abdl-tran->ti-curr-req.ri-ab-req; 

/*  Set  pointer  to  the  current  ABDL  request  */  ^ 

for  (i  *  0;  kc-ptr->kcri-unfin-ret[i)  !=  ASTERIK;  i++) 

kc-ptr->kcri-beg-asterik  =  i;  /*  Mark  postion  of  the  first  asterik  */ 

/*  Calculate  the-maximum  length  of  the  finished  request.  *  j 
kc-ptr->kcri-req-len  =  (strleh(kc-ptr->kcri-unfin-ret)  +  INTSIZE); 
for  (i  =  kc>ptr->kcri-req-lenj  kc-ptr->kcri-unfin-ret[i]  !=  ASTERIK;  i--) 

kc-ptr->kcri-end-asterik  =  i;  /*  Mark  the  position  of  the  last  asterik.  */ 
kc-ptr->kcri-files.nri-curr.fi-fid  = 
fopen(kc-ptr->kcri-files.nri-curr.fi-fname,  "r”); 

/*  Allocate  space  for  the  finished  result.  */ 
abdl-ptr- >ari-req  =  var-str-alloc(kc-ptr->kcri-req-len); 

/*  load  request  up  to  the  first  asterik  */ 
for  (i  =  0;  i  !=  kc-ptr->kcri-beg-asterik;  i+4-) 
abdl-ptr- >ari-req[ij  =  kc-ptr->kcri-unfin-ret[l]; 

j  =  i; 


/*  loads  in  the  min  or  max  value  */ 
num-to-str  (value,  value-str); 
for  (k  =  0;  k  !=  strlen(value-str);  k-h- (-) 
begin  for 

abdl-ptr- >ari-req[jj  =  value-str|kj; 
end  for 


transactions  directly  -fram  the  terminal  a  message  will  be 
displayed  reminding  him  o-f  the  correct  format  and 
special  characters  that  must  be  used.  Since  the 
transaction  list  stores  both  creates  and  queries,  two 
different  access  methods  must  be  employed  to  send  the  two 
types  of  transactions  to  the  KMS.  Therefore,  our 
discussion  branches  to  handle  the  two  processes  the  user 
will  encounter.  ^ 

1  •  Processing  Creates 

When  the  user  has  specified  the  filename  of  creates 
(if  the  input  is  from  a  file)  or  typed  in  a  set  of  creates 
(if  the  input  is  from  the  terminal),  further  user 
intervention  is  not  required.  It  does  not  make  sense  to 
process  only  a  single  create  out  of  .a  set  of  creates  that 
produce  a  new  database  since  they  all  must  be  processed  at 
once  and  in  a  specific  order.  Therefore,  the 

transaction  list  of  creates  is  automatically  executed  by 
the  system.  Since  all  the  creates  must  be  sent  at  once  to 
form  a  new  database,  control  should  not  return  to  MENLJ2 
where  further  transactions  can  be  input.  Instead, 

control  returns  to  MENUl  where  the  user  can  pick  a  new 
operation  or  new  database. 

2 .  PCSEOS i.ng  Qyer  i_es 

In  this  case,  after  the  user  has  specified  his 
mode  of  input,  he  will  conduct  an  interactive  session 


with  the  system.  First,  all  queries  will  be  listed  to  the 


scraen.  As  the  queries  are  listed  from  the  transaction 
list,  a  number  is  assigned  to  each  query  in  ascending 
order  starting  with  the  number  one.  The  number  is 
printed  on  the  screen  beside  the  first  line  of  each  query. 
Next,  an  access  menu,  called  tiENU3,  is  displayed  which 
looks  like  the  following: 

Pick  the  number  or  letter  of  the  action  desired 

(num)  -  execute  one  of  the  {^receding  queries 
(d)  -  redisplay  the  list  of  queries 

(x)  -  return  to  the  previous  menu 

ACTION  - > 

Since  the  displayed  queries  might  exceed  the 

vertical  height  of  the  screen,  only  a  screen  full  of 
queries  will  be  displayed  at  one  time.  If  the  desired 
query  is  not  on  the  current  page,  the  user  can  hit  the 

RETURN  key  to  display  the  next  page  of  queries.  If  the  user 

only  wishes  to  print  a  certain  number  of  lines,  then  after 
the  first  page  is  displayed  the  user  can  enter  a  number  and 
only  that  many  lines  of  queries  will  be  displayed.  If  the 
user  is  only  looking  for  certain  queries,  once  he  has 
found  them  he  does  not  have  to  page  through  the  entire 
transaction  list.  By  hitting  the  q  key,  control  will 

break  from  listing  queries  and  MENU3  will  be  displayed. 
Under  normal  conditions  when  the  end  of  the  transaction  list 
has  been  viewed,  NENU3  will  appear. 


Since  queries  are  independent  items, 
which  they  are  processed  does  not  matter 


the  order  in 


The  user  has 

the  choice  of  executing  however  many  queries  he  desires. 
A  loop  causes  the  query  listing  and  MENLI3  to  be 
redisplayed  after  any  query  has  been  executed  so  that 

further  choices  may  made.  Unlike  processing  creates, 
control  returns  to  liENU2  because  the  user  may  have  more  than 
one  file  of  queries  against  a  particular  database  or  he 
may  wish  to  input  some  extra  queries  ■  directly  from  the 

terminal.  Once  he  has  finished  processing  on  this 

particular  database,  he  can  exit  back  to  MENUl.  to  either 
I  change  operations  or  exit  to  the  operating  system. 

C.  DATA  FORMAT 

When  reading  transactions  from  a  file  or  the  terminal, 

i 

there  must  be  some  way  of  distinguishing  when  one 

transaction  ends  and  the  next  begins.  Transactions  are 
I  allowed  to  span  multiple  lines  as  evidenced  by  a  typical 

nested  SQL  select.  Since  the  system  is  reading  the  input 
line  by  line,  an  end-of -transacti on  flag  is  needed.  In 
our  system  this  flag  is  the  character.  Likewise,  the 

system  needs  to  know  when  the  end  of  the  input  stream  has 
been  reached.  In  our  system  the  end-of -file  flag  is 
represented  by  the  character.  The  following  is  an 


example  of  an  input  stream  with  the  necessary  flags  that 
must  be  included  when  multiple  transactions  are  entered: 


TRANSACTION  #1 
TRANSACTION  #2 

a 


TRANSACTION  #n 
$ 


D.  RESULTS  ; 

T'  When  the  results  o-f  the  executed  ^transact! ons  are  sent 
back  to  the  user's  screen,  they  Mill  be  displayed  exactly 
the  same  way  queries  are  displayed  (See  section  B-2) . 
The  -following  consolidates  the  user's  options: 


*1 

KEY 

FUNCTION 

return 

(number) 

q 

displays  next  screen-ful  o-f  output 

displays  only  (number)  lines  o-f  output 

stops  output,  MENUl  is  then  redisplayed 
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